Bug: Handle synonyms of V3 codecs when serializing to V2 formats

[maxrjones]

As explained in zarr-developers/zarr-python#3332 (comment), for a codec that takes no configuration at all, {'name': 'foo', 'configuration': {}} or {'name': 'foo'} or 'foo' (plain string) are all synonyms, as per the 3.1 spec.

The codepath we use for writing Kerchunk references only works for the {'name': 'foo', 'configuration': {}} version:

VirtualiZarr/virtualizarr/codecs.py

Line 42 in cb2912e

return {"id": name, **num_codec["configuration"]}

We should add support for the'name': 'foo', and 'foo' versions.

cc @d-v-b

[d-v-b]

see zarr-developers/zarr-specs#352 for a spec discussion

[d-v-b]

{'name': 'foo', 'configuration': {}} this is fine, and you can keep using this. You only need to worry about these synonyms when reading data other people produced.

[maxrjones]

{'name': 'foo', 'configuration': {}} this is fine, and you can keep using this. You only need to worry about these synonyms when reading data other people produced.

We don't really have control over the data produced due the parser protocol encouraging external implementations. For example, I first ran into this bug when writing virtual-tiff produced Zarr metadata to a Kerchunk JSON. I think it's likely other parsers would also try to use the {'name': 'foo'} shorthand.