[Merged by Bors] - Config fragment/validation

[nightkr]

Description

This is an alternate take on #425. Essentially, we define a new macro Fragment, which creates a "parallel fragment universe" where everything is optional. For example, given the following types:

#[derive(Fragment)]
struct Outer {
    foo: u32,
    inner: Inner,
}

#[derive(Fragment)]
struct Inner {
    required: String,
    optional: Option<String>,
}

we generate the following fragment variants:

struct OuterFragment {
    foo: Option<u32>,
    inner: InnerFragment, // not an atomic type, so make every subfield optional instead
}

struct InnerFragment {
    required: Option<String>, // was non-optional, so make it optional
    optional: Option<String>, // was already optional, so preserve the type
}

as well as validation functions that turn OuterFragment into Result<Outer> (and an equivalent for Inner), while giving us the full context when a validation error occurs.

This allows us to safely deserialize and merge the fragment variants, and only afterwards validate that all required options are present in the final merged configuration.

This is a pretty big and breaking change, since it moves all Serialize and Deserialize impls on the resources into the fragment variants.

Review Checklist

• Code contains useful comments
• (Integration-)Test cases added (or not applicable)
• Documentation added (or not applicable)
• Changelog updated (or not applicable)
• Cargo.toml only contains references to git tags (not specific commits or branches)

Once the review is done, comment bors r+ (or bors merge) to merge. Further information

[nightkr]

There is an example conversion of zookeeper-operator: stackabletech/zookeeper-operator#530

[adwk67]

Some minor comments/questions aimed at clarifying things.

[nightkr]

This depends on GREsau/schemars#167

[adwk67]

lgtm.
(q: should we refer to a tag rather than a branch - feature/custom-bound - for schemars_derive? Or is that going to remain static until the change is merged upstream?)

[nightkr]

(q: should we refer to a tag rather than a branch - feature/custom-bound - for schemars_derive?)

No, we should probably hold off on merging this until their branch is merged and released.

[adwk67]

(q: should we refer to a tag rather than a branch - feature/custom-bound - for schemars_derive?)

No, we should probably hold off on merging this until their branch is merged and released.

OK.

[nightkr]

@adwk67 Are we ok merging this now?

[adwk67]

@adwk67 Are we ok merging this now?

yes, fine by me.

[nightkr]

bors r+

[bors]

Pull request successfully merged into main.

Build succeeded:

• All tests passed