C21328 mutation tracking version

[bdeggleston]

Thanks for sending a pull request! Here are some tips if you're new here:

• Ensure you have added or run the appropriate tests for your PR.
• Be sure to keep the PR description updated to reflect all changes.
• Write your PR title to summarize what this PR proposes.
• If possible, provide a concise example to reproduce the issue for a faster review.
• Read our contributor guidelines
• If you're making a documentation change, see our guide to documentation contribution

Commit messages should follow the following format:

<One sentence description, usually Jira title or CHANGES.txt summary>

<Optional lengthier description (context on patch)>

patch by <Authors>; reviewed by <Reviewers> for CASSANDRA-#####

Co-authored-by: Name1 <email1>
Co-authored-by: Name2 <email2>

The Cassandra Jira

[iamaleksey]

One thing we did when implementing equivalent functionality for Accord was inspect existing serializers and convert the majority of them to the unversioned variant. I expect most of the lower level serializers to not change (ever), and if they ever do, we can convert them to versioned variants one case-by-case basis.

[iamaleksey]

I think this is dead logic? And also Version itself should have an unversioned serializer.

[iamaleksey]

I can see that this skips the version, but it could be made more clear.

Also, realizing that we are writing out a mutation id (now 1 byte fatter) for all mutations, even if if a keyspace has no mutation tracking enabled, for none(), and I don't think that is fine - that's 17 bytes of waste for folks not opted into MT.

[iamaleksey]

I reckon we could use 0 byte for none() here.

[iamaleksey]

At the high level, I think this is done on a slightly wrong level. MutationTrackingSerializer writes out the version even for nested serializers, redundantly - instead of it being specified just once at the outermost point - just for MT related messages. Accord does this better I believe - with EmbeddedAsymmetricVersionedSerializer, which we could reuse.

It's probably the wrong thing to introduce a different style of sub-messaging-service versioning here. Should mimic how Accord does it, and, where makes sense, reuse some of its code as well - but not have two parallel approaches.

[iamaleksey]

I can make the changes that I have in mind if you like.

[iamaleksey]

Pushed pt. 1 of the changes, but there is more to do.

As part of the audit, reviewed existing implementations of MT serializers and fixed some low hanging fruit issues: hand-rolled collection serializers, use of fixed size ints for known small int values (instead of vints), etc.

Doing the rest correctly is actually relatively involved. We have MT structures interleaved in non-MT structures in a few places (such as mutation id inside Mutation, coordinator ack info in Message param map, the interleaving in IDataResponse, MT structures inside regular streaming messages, and in SSTableMetadata).

Some of these can simply be made unversioned (MutationId), some need to either be made unversioned or be moved inside an MT message (coordinator ack info), some should be pulled out of non-MT structures altogether. There are also odd parallel versioning schemes running (think serializationVersion inside TrackedDataResponse).