feat(buildsys): embed guest variant images via build-variant guest-images

[jmt-lab]

Add a declarative guest-images field to a host variant's
[package.metadata.build-variant] manifest that embeds the disk-image
artifacts of one or more already-built guest variants into the host's
rootfs. This enables shipping variant-A images as content inside
variant-B (e.g. installer media, recovery partitions, AMI-bundled
secondaries) without introducing a new package type or CLI surface.

Manifest schema:

[package.metadata.build-variant.guest-images]
inner-variant = "/usr/share/bottlerocket/guests/inner"

[build-dependencies]
inner-variant = { path = "../inner-variant" }

buildsys build-variant validates each entry: the key must appear in
[build-dependencies], the target must itself be a build-variant,
the value must be an absolute install path, and a variant may not
reference itself. Validated entries are threaded through a
GUEST_IMAGES build-arg (newline-delimited
<guest>:<install_path>:build/images/<arch>-<guest>/<version>) into the
imgbuild Dockerfile stage, where rpm2img (via the new
guest-images-helper) cp -as each guest's image directory into
${ROOT_MOUNT}<install_path> after rpm -iv and before SELinux
relabel, so embedded files inherit correct labels.

Tests:

• Unit: test_build_variant_with_guest_images,
  test_build_variant_without_guest_images,
  test_build_type_default_package_unchanged, plus
  validate_guest_image_entries and guest_image_variant_deps
  coverage for invalid names/paths, self-reference, missing build-dep,
  transitive-only build-dep, and the happy path.
• Fixtures: tests/projects/guest-images-kit (host wrapper-variant
  embedding an inner-variant) and guest-images-graph (direct,
  transitive, and self-referential guest deps).
• Integration (#[ignore], requires Docker):
  test_twoliter_build_variant_consumes_guest_images asserts the
  guest variant builds transitively and the host variant produces
  image artifacts.
  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.

[arnaldo2792]

First quick pass, this is the one line I would really like to keep as downstreams requested.

[arnaldo2792]

PCR predictions might not, but the sboms yes. So do please include them. Ideally, the SBOM of the host should include it. Basically, treat it as another package that should appear in the host's SBOM.

[ginglis13]

@jmt this comment needs updating now that guest SBOMs are included in the host

[ginglis13]

I want to flag this for discussion - how we might include guest OS application inventory in the host

One option is to merge the guest package inventory into the host application inventory. We can distinguish between guest OS and host OS packages clearly, such as a -guest suffix to all package names appearing in the one application-inventory that are from the guest OS. This will be necessary i.e. if names are shared between guest and host - we can't have overwriting entries.

The other option would be to provide guest inventory in the host as a completely separate file, but this wouldn't integrate out-of-the box with any tooling around inventory that expects just application-inventory.json.

[strategicpause]

Playing devil's advocate a bit: Why not just merge them into a single list and not distinguish between the two? At the end of the day if ArtifactA-1.0 is present in both the guest and the host, we will need patch that host, and all artifacts regardless of where they come from. If one of the artifacts is missed, then ArtifactA-1.0 and ArtifactA-1.1 will show up in the resulting SBOM, right?

[strategicpause]

What feedback mechanism exists to tell you when this list is out of sync? For example, warnings?