Support a list of codecs in place of a single compressor field

[jbms]

Per what seemed to be the consensus reached at the zarr meeting on 2022-07-27, this replaces the compressor field in the array metadata with a codecs field that can specify a list of codecs.

[martindurant]

I am very much in favour of this idea

[rabernat]

This makes sense to me too.

[martindurant]

There is an implicit assumption here, that if the last codec in an encoding chain still produces an array as opposed to bytes (or the list is empty), then the output to storage is the bytes (memory buffer) of that array. That's like the "null" or "dummy" codec mentioned elsewhere. I don't think we need that codes if we are explicit about it here.

[jbms]

There is an implicit assumption here, that if the last codec in an encoding chain still produces an array as opposed to bytes (or the list is empty), then the output to storage is the bytes (memory buffer) of that array. That's like the "null" or "dummy" codec mentioned elsewhere. I don't think we need that codes if we are explicit about it here.

See here: https://github.com/zarr-developers/zarr-specs/pull/153/files#diff-90d755c4d7549e4ab133911db1e21cda80aeba463eb25c00a76501c2ab89a5d2R836

[martindurant]

Perfect, thanks @jbms

[jstriebel]

LGTM as well. Is there missing anything for this to be merged? cc @joshmoore @MSanKeys963 @alimanfoo @jakirkham We can cherry-pick the change onto the ZEP1-review branch then as well.

[jstriebel]

LGTM as well 👍

[joshmoore]

Merging per all the 👍s. One thing this does make me aware of though, is that we should probably start maintaining a list of explicit changes now before the list becomes too long to be applied to the existing V3 implementations.