Add version negotiation for migration protocol

[Coffeeri]

This PR implements https://github.com/cobaltcore-dev/cobaltcore/issues/464 and introduces version negotiation for the migration protocol.

Steps before Merging

• Add testing: migration between two CHV versions (one with version negotiation and one without)

[hertrste]

A second requirement is that this PR must not introduce a breaking protocol change by itself. To achieve that, it reuses the existing 6 padding/ reserved bytes in the START request and OK response at the beginning of the migration handshake instead of adding a new message type.

Would it be possible to 1.) change CHV so it ignores new fields in Commands that it does not yet know about and gracefully handle missing fields in responses and 2.) add new fields that encode the supported versions?

This way, we could do changes to the migration protocol later easier, as long as they don't change the semantics of existing fields. We also shouldn't be breaking then (if we do it in those 2 steps and do not skip versions when upgrading).

Not sure if really required but at least have a short discussion about it.

[phip1611]

Thanks for the great work! Left some remarks

[arctic-alpaca]

Would it be possible to 1.) change CHV so it ignores new fields in Commands that it does not yet know about and gracefully handle missing fields in responses and 2.) add new fields that encode the supported versions?

CHV doesn't know anything about the bytes it reads from the network. The only way to go from bytes to struct is to apply some known conversion, which basically means treating a predefined amount of bytes as type T. CHV can ignore some defined amount of unused space (like the padding that @Coffeeri is using in this PR).
Ignoring unknown fields can, as far as I know, only be done by using a completely different data format like JSON or any other self describing data format.

If either side does not implement version negotiation yet, the handshake falls back to the legacy v0 behavior.

Isn't that just treating the current implementation as version 0 and the negotiation just works/fails depending on whether both sides support version 0?

@Coffeeri I think the general design of the handshake is good. Please assign me as one of the reviewers when code reviews are in order.

[Coffeeri]

Would it be possible to 1.) change CHV so it ignores new fields in Commands that it does not yet know about and gracefully handle missing fields in responses and 2.) add new fields that encode the supported versions?

This way, we could do changes to the migration protocol later easier, as long as they don't change the semantics of existing fields. We also shouldn't be breaking then (if we do it in those 2 steps and do not skip versions when upgrading).

@hertrste
I think this would only be possible when using a serialized data type as @arctic-alpaca described. The C-style struct of Request/Response limits us here.

Isn't that just treating the current implementation as version 0 and the negotiation just works/fails depending on whether both sides support version 0?

Yes, exactly. We should handle v0 (impl without version negation) as a separate version, but we don't have to support it in the future if we have a migration path via an intermediate migration protocol version.
But in some prior iterations of mine, I had made the v0 implementation explicit, such as explicitly sending the legacy start request/ok response. We can simplify this and don't need to branch this out, as these fields are ignored in the worst case.

---

Does the overall design suite the others as well?
I think we have settled on:

• exploit the prior six byte padding for version transport in START/ first OK
• selected version must be negotiated to the highest common version

Open questions to the discussion:

• How will we use the selected version: Will we simply plumb the selected version through our codebase and branch on selected version? I think having complete separate crates for three versions [prior, current, nightly], as suggested by @arctic-alpaca, would be very difficult as we don't have a clear migration logic separation, much of which lives in the vmm crate.
• How should we define our current and prior versions as an elegant data structure? I agree with @phip1611 that the following versioning and aliases could be improved:

impl MigrationProtocolVersion {
    pub const LEGACY: Self = Self::V0;
    pub const CURRENT: Self = Self::V1;

We should be careful not to model this as something like our planned 3-version support [prior, current, nightly], because protocol versions need stable, explicit identities per release. Each concrete protocol revision should keep its own defined version number, rather than being derived from moving labels. I'd like it to be explicit.

[amphi]

Why does the sender have a "minimum supported version"? I think the sender should just send using the newest version it supports, and the receiver has to decide whether it can support that version.

Otherwise, we'd give the sender the ability to send using an older protocol than it supports. In which case would that be helpful?