Add ZstdSerializer, change Key to include "domain"

[bisho]

Changes:

• Add ZstdSerializer. Can be configured to default to zlib for backwards-compatibility. Can use zstd dicts. Can decompress and deserialize anything MixedSerialized supported before.
• Change Key to include "domain"
• Change Key to include skip compression, so if the data is compressed on user space, it wont be re-compressed again, or if the data is too sensitive and needs to skip compression performance hit.
• Change Key, removing the old unicode flag. It is no longer needed (with rust serialization key encoding just works, no mater unicode, binary or anything).

The idea is that domain can be used to mark keys as belonging to a use-case domain, and specify custom Zstd dictionaries for some domains. Also domains can be used to track per-domain counters (hits, hit ratio, etc), but this is not implemented yet.

[tonycosentini]

Love the domain concept - super simple.

Would it make sense to also allow different serializers for different domains? My hunch is no because it makes things very complicated (in particular, the application code now controls more details around compatiblity...).

[bisho]

Love the domain concept - super simple.

Would it make sense to also allow different serializers for different domains? My hunch is no because it makes things very complicated (in particular, the application code now controls more details around compatiblity...).

We can definitely build a new serializer that routes serialization depending on domain, it can use composition to reuse existing ones.

Serializing in jsonb our data-only objects might be very interesting if we get out of the python-only world and need to share cache. I think the domain thing in the key allows to build anything we want, but I would try to keep a single serializer per client. Just make a proxy serializer if you need custom things.