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).

[d-v-b]

this looks great, I had some minor suggestions.

[dstansby]

Thanks for this, and thanks for fixing some issues along the way! For the user-facing issues you fixed, can you add a short entry in docs/release-notes.rst, so users know what's been fixed?

[maxrjones]

Thanks for this, and thanks for fixing some issues along the way! For the user-facing issues you fixed, can you add a short entry in docs/release-notes.rst, so users know what's been fixed?

For sure, I'm hoping to find time to address the remaining comments within the next day or two. I'll add release notes at that time.

[maxrjones]

I believe that I've addressed all the suggestions (thank you for the review, Davis!), except that I will need to wait on clarification about the expected behavior for get/set on closed stores before any final changes/changelog additions.

[d-v-b]

I don't think my questions about open / closed behavior should block this PR. I can spin that out into a separate issue.

[maxrjones]

I don't think my questions about open / closed behavior should block this PR. I can spin that out into a separate issue.

Sounds good, thanks. There's still a couple new untested lines still in this PR - I should have time to fix that tomorrow morning.

[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]

Could these new abstract methods get a changelog entry? I also presume this is a breaking change, because anyone implementing a child of StoreTests will now be forced to implement these methods?

[maxrjones]

Yes, I can mention it in the changelog entry. I do not consider this a breaking change because the previous 'NotImplementedError' caused these tests to fail unless they were implemented in the inheriting class. I think this is just a more Pythonic way to indicate that they need to be implemented.

[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)?