Migrate to schnauzer v2 for configuration file templates

[cbgbt]

NOTE This is against the ootb-settings-extension feature branch.

Issue number:
#3133

Description of changes:

• Adds support for "optional" settings extensions in templates. This lets us e.g. use AWS settings if the extension is installed, but not otherwise. Right now, the implementation does nothing because there's no concept of a setting being present or not.
• Uses the new schnauzer v2 rendering library in thar-be-settings, and changes all current templates to the new format
• Simplify schnauzer implementation by moving some Option types to have a serde(default).

Existing templates were found by checking for all files installed into %{_cross_templatedir}.

Testing done:

• All built-in test suites pass
• Booted and checked logs/behavior of a k8s and ecs variant
• Fuzz testing (I'm generating a corpus of settings objects and asserting that the old template system produces the same results as the new one)

Terms of contribution:

By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.

[cbgbt]

This is what I get for doing some rebasing and not re-running the build 😅

[bcressey]

I keep seeing this and wondering if we should make the +++ delimiter optional, but then I think what a weird template this is and start wondering why it's a template at all.

We've gotten to a good place as far as ownership for the settings themselves and for related helper functions, but we still don't have a clear picture for who should own the template, which seems like it's inherently a cross-cutting concern that has to reflect the builder's intent.

For Kubernetes, we try to have a one-size-fits-all template, but it ends up requiring a lot of extensions. For containerd, we package all the templates with the software, which leads to this no-op template.

[cbgbt]

I believe we must always require the +++ delimiter at the start of a template, otherwise it is impossible for the parser to appropriately disambiguate a template body with +++ in it, especially if that body is a TOML document.

As far as who owns the templates, I've been thinking they may want to live in their own sub-packages that can be overridden, and use e.g. Provides: template(kubelet-kubeconfig))

[cbgbt]

Re-reading this while not being in a rush, I agree that this probably shouldn't be a template at all.

[bcressey]

Is it possible to make any_enabled a std helper or does it assume too much about the data shape to work for anything other than Kubernetes?

[cbgbt]

^ Rebases onto develop

[cbgbt]

The above:

• Fixes two templates that changed in develop during the rebase
• Moves the any_enabled helper to std as requested by @bcressey

[cbgbt]

This should be ready to merge. I finished fuzz testing, which uncovered two bugs:

• I missed a comma in one of the template headers
• helpers in handlebars implement either call or call_inner depending on how they are defined. call_inner is composable, but call is not. I modified our wrapper helper to pass calls to both through to the wrapped helper.

[cbgbt]

Some details about fuzz testing:

• I implemented random model generation for Bottlerocket in this branch. It's a mess and can't really be done in a maintainable way to merge upstream, but it's helpful here.
• I generated 5k settings JSON blobs for each variant
• I wrote a tool which clones two Bottlerocket branches and renders a list of templates from both, one with schnauzer::v1 and the other with schnauzer::v2 and compares the ouput.
• The compared templates are these
• I did have to make a few changes to helpers to avoid network calls and to make iteration through HashMaps deterministic, but otherwise left things unchanged.

All 135,000 models now render identically for both tools.

[stmcginnis]

Great testing coverage!