define store behavior via protocols

[d-v-b]

over in #3719 I take advantage of the ability of some "niche" storage backends (memory and local files) to write subchunks inside a shard. This is a huge performance win under the right conditions. It requires a set_range(key, value, byte_range) method, which most stores will not support.

Our monolithic Store abc makes this situation -- methods some stores have, but others do not -- hard to express. We either use boolean attributes like supports_x, hasattr, or other hacks. Alternatively, we define a protocol like SupportsSetRange, and have store classes that support set_range inherit from SupportsSetRange. IMO this is the best approach.

So... why don't we replace the entire Store abc with protocols? This seems like a much better way to express the compositional nature of storage backends than a monolithic abstract base class.

cc @kylebarron

[kylebarron]

Big +1 towards using protocols. I think Zarrs does something similar in zarrs_storage with its various traits on the Rust side.

I think you should be able to have protocols be intersected as needed.