A decoded-chunk cache for v3 reads (revisiting the v2-era #278 / #306) #4306

zarr-python 2 had LRUStoreCache; v3 currently has no caching layer, so every read decodes every chunk it touches, in full. Any consumer with overlapping reads pays the cliff.

Measured on a chunked OME-Zarr store read in sliding slabs (zarr 3, local NVMe): the same 2.1 GB of useful bytes cost 1.9 s when read in 256-row slabs and 28 s in 6-row slabs, a 15x penalty, because neighbouring slabs re-decode the same chunks over and over.

This was discussed in the v2 era: #278 asked for exactly this and #306 implemented a ChunkCache holding decoded chunks passed to Array (never merged), and #382 sketched layered caching. The v3 architecture seems friendlier to it than v2 was.

What we run in production and would be glad to upstream: a byte-capped decoded-chunk cache around Array reads (post-decode, so a hit is a memcpy), default off, with an optional eviction hook so an application that knows its read schedule can supply Belady-style eviction. With the hook, our workload's decode count drops from 148 (plain LRU) to 138, against a theoretical floor of 126.

Is there current interest in a v3 chunk cache, and would a design along those lines (cache on the Array, byte cap, optional eviction callback) be considered? I can open a PR with the implementation and the benchmarks.