feat(stackable-versioned)!: Add conversion tracking

[Techassi]

Part of stackabletech/issues#642

Caution

It should be noted, that only simple additions of fields can be tracked across conversions. Complex action combinations and other types of changes cannot be tracked. Support for this will be added in the future.

Summary

• BREAKING: The macro can only be applied to modules now.
• BREAKING: Crate overrides are now done at the module level, not the container level.
• BREAKING: Top-level CRD specs now use crd(...) instead of k8s(...).
• BREAKING: The (optional) status needs to implement Default.
• The conversion tracking is behind the experimental_conversion_tracking flag.
• A new nested flag was added to mark individual fields as nested (indicating that the sub struct also contains changes which need to be tracked).

#[versioned(
    version(name = "v1alpha1"),
    version(name = "v1alpha2"),
    version(name = "v1beta1"),
    version(name = "v2"),
    version(name = "v3"),
    options(k8s(experimental_conversion_tracking))
)]
pub mod versioned {
    #[versioned(crd(group = "test.stackable.tech", status = "PersonStatus"))]
    #[derive(Clone, Debug, CustomResource, Deserialize, JsonSchema, Serialize)]
    #[serde(rename_all = "camelCase")]
    pub struct PersonSpec {
        username: String,

        // In v1alpha2 first and last name have been added
        #[versioned(added(since = "v1alpha2"))]
        first_name: String,

        #[versioned(added(since = "v1alpha2"))]
        last_name: String,

        // We started out with a enum. As we *need* to provide a default, we have a Unknown variant.
        // Afterwards we figured let's be more flexible and accept any arbitrary String.
        #[versioned(added(since = "v2"), changed(since = "v3", from_type = "Gender"))]
        gender: String,

        #[versioned(nested)]
        socials: Socials,
    }

    // Ideally, we want this to be versioned independently from the CRD spec above. The addition
    // of the `mastodon` field would then require a change on the `socials` field above. But as
    // mentioned, currently we don't support individual versions nor complex action + nested
    // combinations.
    // This still demonstrates that tracking works in nested sub structs on a basic level (for now).
    #[derive(Clone, Debug, Deserialize, Serialize, JsonSchema)]
    pub struct Socials {
        email: String,

        #[versioned(added(since = "v1beta1"))]
        mastodon: String,
    }
}

#[derive(Clone, Debug, Deserialize, Serialize, JsonSchema)]
pub struct PersonStatus {
    pub alive: bool,
}

Learnings from this PR

• We need per-container versions. The current mechanism doesn't make sense for more complex CRDs with multiple sub structs (at different versions).
• We need fallible conversions.
• We need to support to track other types of changes to be able to use this on real CRDs.
• We need to integrate with Serde (for renames, flattening, untagged).

[sbernauer]

LGTM % remaining comment and conflicts

[sbernauer]

LGTM but we have test failures

[Techassi]

Ah! This was allowed previously. I will update the test.