Expose LatencyStore as public API

[TomNicholas]

Closes ##3358

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/user-guide/*.rst
• Changes documented as a new file in changes/
• GitHub Actions have all passed
• Test coverage is 100% (Codecov passes)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.54%. Comparing base (926a52f) to head (eb4aa28).
⚠️ Report is 199 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3359   +/-   ##
=======================================
  Coverage   94.54%   94.54%           
=======================================
  Files          78       79    +1     
  Lines        9423     9427    +4     
=======================================
+ Hits         8909     8913    +4     
  Misses        514      514           

Files with missing lines	Coverage Δ
src/zarr/storage/__init__.py	95.23% <100.00%> (+0.23%)	⬆️
src/zarr/storage/_latency.py	100.00% <100.00%> (ø)
src/zarr/testing/store.py	100.00% <ø> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[d-v-b]

pre-commit is mad about a docstring but otherwise this looks g2g

[maxrjones]

I'm a bit confused about why this is necessary. It's extremely common for downstream libraries to use functions from the testing modules of libraries (e.g., np.testing.assert_..., xr.testing.assert_...). Why do we need a different approach here? I question whether this change is worth it because putting LatencyStore in the same namespace at the other stores would add confusion for people who just want to use Zarr-Python, not develop downstream libraries.

[TomNicholas]

Why do we need a different approach here? I question whether this change is worth it because putting LatencyStore in the same namespace at the other stores would add confusion for people who just want to use Zarr-Python, not develop downstream libraries.

I actually agree - I think it would make more sense to expose LatencyStore within a zarr.testing.storage namespace. That still requires a PR though (which could be this one), because it's currently in zarr.testing.store, and not documented in the public API docs.