Improve test coverage for storage classes

[maxrjones]

This PR improves the test coverage for the various storage classes. While testing the storage classes, I fixed a few issues:

• Implement open() for LoggingStore
• Add _is_open property and setter for WrapperStore
• Use stdout rather than stderr as the default stream for LoggingStore
• Ensure that ZipStore is open before getting or setting any values
• Update equality for LoggingStore and WrapperStore such that the types much be equal. This is an opinionated change. For example, previously a LocalStore and LoggingStore instance could be evaluated as equal, whereas now they are distinct.

Here's the change in coverage:

src/zarr/abc/store.py                    84% -> 93%
src/zarr/storage/__init__.py             94% -> 94%
src/zarr/storage/_utils.py               94% -> 97%
src/zarr/storage/common.py               80% -> 91%
src/zarr/storage/fsspec.py               25% -> 90%
src/zarr/storage/local.py                86% -> 92%
src/zarr/storage/logging.py              62% -> 96%
src/zarr/storage/memory.py               82% -> 85%
src/zarr/storage/wrapper.py              56% -> 94%
src/zarr/storage/zip.py                  96% -> 97%
src/zarr/testing/store.py                92% -> 99%

src/zarr/storage/memory.py coverage is low because it includes the GPUStore and I don't have a test environment with cuda. I'm opening this PR now even though it's not at 100% coverage because I don't expect to have much time to work on it during the week and would rather the PR not get stale if the team has time for a review.

The set partial values methods are addressed separately because they require discussion (xref #2688).

[dstansby]

Thanks for this, big 👍 for improving our testing.

Two major points:

• Since StoreTests is public API, we should carefully document everything that's been changed/added in the release notes. I added some comments on this PR inline to changes I spotted that need a release note.
• Like @d-v-b, I am confused by Improve test coverage for storage classes #2693 (comment) - would be good to discuss/resolve that comment

[dstansby]

Yes, this is also surprising to me!

[maxrjones]

Like @d-v-b, I am confused by #2693 (comment) - would be good to discuss/resolve that comment

@d-v-b @jhamman could I join the developers meeting tomorrow to discuss the Store open and set behavior (xref #2688)?

[martindurant]

Labeler is fixed now on main

[dstansby]

Thanks for all the changelog updates! I added a couple of minor suggestions. I think https://github.com/zarr-developers/zarr-python/pull/2693/files#r1913045841 is an outstanding question that still needs resolving too?

Other than that, is this ready to go from your point of view @maxrjones?

[maxrjones]

Thanks for all the changelog updates! I added a couple of minor suggestions. I think #2693 (files) is an outstanding question that still needs resolving too?

Other than that, is this ready to go from your point of view @maxrjones?

Thanks! Yes, I believe this is ready to go aside from the open questions about ._is_open. I will raise a dedicated issue for that discussion shortly.

[jhamman]

Thanks so much for doing this @maxrjones. This is a great improvement AND exposes some rough edges in our store API. The good news there is that I think there are some relatively easy improvements we can make to clean up those rough edges.