LRUStoreCache: cache "contains" by contains checks

[madsbk]

Fixes #1497 by caching LRUStoreCache.__contains__ calls individually.

Apparently in ZarrTiffStore, a successful "contains" check of key doesn't necessarily means that key is in ZarrTiffStore.keys().

E.g. if key is a string and not in ZarrTiffStore.keys(), it still might be "contained" by ZarrTiffStore, see https://github.com/cgohlke/tifffile/blob/master/tifffile/tifffile.py#L12222

I guess that is why LRUStoreCache has both a key and a contains cache?

TODO:

• Add unit tests and/or doctests in docstrings
• [ ] Add docstrings and API docs for any new/modified user-facing classes and functions
• [ ] New/modified features documented in docs/tutorial.rst
• Changes documented in docs/release.rst
• GitHub Actions have all passed
• Test coverage is 100% (Codecov passes)

cc. @cgohlke

[codecov]

Codecov Report

Merging #1499 (d2c7ef9) into main (f542fca) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##              main     #1499   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           37        37           
  Lines        14729     14735    +6     
=========================================
+ Hits         14729     14735    +6     

Files Changed	Coverage Δ
zarr/_storage/v3.py	100.00% <100.00%> (ø)
zarr/storage.py	100.00% <100.00%> (ø)
zarr/tests/test_storage.py	100.00% <100.00%> (ø)

... and 3 files with indirect coverage changes

[cgohlke]

Thank you. I can confirm that this fixes issue #1497.

[rabernat]

Apparently in ZarrTiffStore, a successful "contains" check of key doesn't necessarily means that key is in ZarrTiffStore.keys().

Could someone elaborate on why this is? It seems inconsistent--certainly different from how a normal mutable mapping works.

[cgohlke]

Apparently in ZarrTiffStore, a successful "contains" check of key doesn't necessarily means that key is in ZarrTiffStore.keys().

Could someone elaborate on why this is? It seems inconsistent--certainly different from how a normal mutable mapping works.

Good question.

1. So far it has not been required AFAIK. Although I felt uneasy to rely on it without documentation.
2. It seems excessive (to the point being unusable) to have keys() return potentially many millions of short strings to test one membership.
3. It is not simple to check if a chunk is actually contained in a TIFF file (https://github.com/cgohlke/tifffile/blob/7b162f968bc978bd374dfe87f05a913e82afd283/tifffile/tifffile.py#L12973-L13018)

[rabernat]

Thanks for this PR!

This seems like an acceptable solution to me. I still find it strange that __contains__ and keys() return inconsistent results, but I accept that behavior is desired for some stores.

@madsbk, please complete the TODO checklist (or cross out irrelevant items).

[madsbk]

Added release notes, I think this can be merged