feat!: store-defined concurrency limits

[d-v-b]

edit: this PR has now improved since its initial submission. Here are the key changes:

• async.concurrency is gone from the global config, using this setting triggers a warning.
• concurrency is managed by store instances
• concurrent_map is gone. asyncio.gather is used instead, because concurrency limits are now the store's concern.
• a ConcurrencyLimiter mixin adds a semaphore-based concurrency limit via a decorator
• Non-remote stores like LocalStore and MemoryStore have no concurrency limits. This results in a large performance improvement.
• FSSpecStore and ObjectStore have a default concurrency of 50.

[dcherian]

Nice, the other one that bugs me when profiling is

zarr-python/src/zarr/codecs/zstd.py

Line 79 in b3e9aed

return await asyncio.to_thread(

[maxrjones]

@d-v-b do you have thoughts on how downstream libraries would interact with Zarr's concurrency limit? Would those set there own concurrency approaches (e.g., global or per function) or could there be a way to share the limit with Zarr?

[d-v-b]

@maxrjones this PR is moving away from a global concurrency limit because it's actually very hard to implement a top-down concurrency control in our codebase. the new direction I'm taking with this PR is for each store to set its own concurrency limit. for stateless stores like local and remote (basically anything except zip), concurrency-sensitive applications should be able to cheaply create store instances with concurrency limits tuned to the needs of the application.

[d-v-b]

this is ready for a look. The basic idea is that we make concurrency limits an implementation detail of a particular store and thereby remove all concurrency limiting logic from array / group routines. Some stores will have no concurrency limits (e.g., memory and local storage) and so their performance will go up. Stores that actually benefit from a concurrency limit (remote stuff) has the default limit of 10 but that's something we can play with.

To cut down on boilerplate we (claude and I) define a ConcurrencyLimiter base class that encapsulates the concurrency limiting logic. This means taking a concurrency limit (int | none) and creating a semaphore (or a nullcontext if there's no limit). We also define a decorator that an be used to wrap a should-be-concurrency-limited method on a class that inherits from the ConcurrencyLimiter base class.

[d-v-b]

quick check: are there any storage backends where we need a concurrency limit defined in zarr-python? I'm wondering if this PR should actually just be removing any reference to concurrency limits, since this seems to be a storage backend concern.