VersionMap must contain all structs at their current versions

[ioanachirca]

Signed-off-by: Ioana Chirca [email protected]

If we are (de)serializing at the latest version from VersionMap, check that the struct's current version matches the version from the map. If it doesn't, it means that the Version Map is outdated.

Running cargo bench in firecracker/src/snapshot crate after updating the versionize_derive dependency gives us these mean times:

Test	Mean
Serialize	320.47 us
Serialize + crc64	378.65 us
Deserialize	59.05 us
Deserialize + crc64	224.21 us

The extra checks do not introduce a regression (current baseline here)

Description of Changes

• add a check for outdated Version Map
• bump the crate version (the check requires VersionizeError to be in scope, which is not necessarily true for the crates using versionize_derive)

License Acceptance

By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache 2.0 license.

PR Checklist

[Author TODO: Meet these criteria.]
[Reviewer TODO: Verify that these criteria are met. Request changes if not]

• All commits in this PR are signed (git commit -s).
• The reason for this PR is clearly provided (issue no. or explanation).
• The description of changes is clear and encompassing.
• Any required documentation changes (code and docs) are included in this PR.
• Any newly added unsafe code is properly documented.
• Any user-facing changes are mentioned in CHANGELOG.md.

[sandreim]

Changelog update required.

[lauralt]

Looks good. Some comments should be modified and also the commit message should be updated with the struct/union/enum observation (plus verion typo).

[alexandruag]

This looks good, but has a bit of downside in the sense it doesn't help with structures where we implement Versionize manually. Looks like doing the check in VersionMap::get_type_version itself covers more cases. That's not really possible right now because that method expects the type_id directly as a parameter, so we don't have access to the current version of the corresponding type. Would it make sense to change its signature to something like pub fn get_type_version<T: Versionize>(&self, root_version: u16) -> u16?

[sandreim]

This looks good, but has a bit of downside in the sense it doesn't help with structures where we implement Versionize manually. Looks like doing the check in VersionMap::get_type_version itself covers more cases. That's not really possible right now because that method expects the type_id directly as a parameter, so we don't have access to the current version of the corresponding type. Would it make sense to change its signature to something like pub fn get_type_version<T: Versionize>(&self, root_version: u16) -> u16?

This also mitigates the binary size increase due to the current solution with generated code.

[ioanachirca]

This looks good, but has a bit of downside in the sense it doesn't help with structures where we implement Versionize manually. Looks like doing the check in VersionMap::get_type_version itself covers more cases. That's not really possible right now because that method expects the type_id directly as a parameter, so we don't have access to the current version of the corresponding type. Would it make sense to change its signature to something like pub fn get_type_version<T: Versionize>(&self, root_version: u16) -> u16?

Sounds better this way, thanks for pointing this out!