Feature: Implement multithreaded reads in hdf5

[OmkarAgnihotri]

This Pull Request implements a Proof-Of-Concept for multithreaded chunk
reads for hyperslab selections over chunked datasets in hdf5.

The high level idea is to bypass the thread unsafe chunk cache (H5D_rdcc_t)
and the page buffer (H5PB_t).

This works in two phases:

1. Serial phase
   • Accumulate chunk addresses/offsets
2. Parallel phase
   • Read raw data for the given chunks
   • Apply filter pipelines
   • Copy data to appropriate locations in the memory space

---

Important

Implements multithreaded chunk reads for hyperslab selections in HDF5, bypassing thread-unsafe components and using OpenMP for parallel processing.

• Behavior:
  • Implements multithreaded chunk reads for hyperslab selections in H5D__chunk_read() in H5Dchunk.c.
  • Bypasses thread-unsafe H5D_rdcc_t and H5PB_t.
  • Uses OpenMP for parallel processing.
• Structures:
  • Adds H5D_chunk_info_light_t in H5Dpkg.h for parallel I/O operations.
• Parallel Processing:
  • Serial phase: Accumulates chunk addresses/offsets.
  • Parallel phase: Reads raw data, applies filters, and copies data to memory.

^{This description was created by for 8cc195a. You can customize this summary. It will automatically update as commits are pushed.}

[gheber]

Great work @OmkarAgnihotri .

Just to clarify the use case/assumptions:

1. You are not looking for multiple application threads calling the public API (H5Dread), i.e., your proposal is something that would be supported in non-thread-safe library builds.
2. Fixed‑size datatype, no conversion/xform.
3. Simple hyperslab selections (no point selections).
4. Read‑only.
5. No filters (or only filters that are known re‑entrant and don’t touch global state).
6. Bypass the chunk cache and metadata cache where possible.

Is that a fair description?

[OmkarAgnihotri]

Just to clarify the use case/assumptions:

1. You are not looking for multiple application threads calling the public API (H5Dread), i.e., your proposal is something that would be supported in non-thread-safe library builds.
2. Fixed‑size datatype, no conversion/xform.
3. Simple hyperslab selections (no point selections).
4. Read‑only.
5. No filters (or only filters that are known re‑entrant and don’t touch global state).
6. Bypass the chunk cache and metadata cache where possible.

Is that a fair description?

Yes, all the 6 points exactly describe the use case. Thanks @gheber for the clear summary.

[gheber]

I'd add:

7. The VFD used is known to be re‑entrant for concurrent reads (which sec2 is).
8. The OMP parallel region does only read + memcpy on disjoint regions.