Install UKI Addons globally

[Johan-Liebert1]

Until now we were scoping passed in UKI Addons to specific deployments,
but usecases like ignition, luks (for now at least), require the addons
to be applied to all deployments

Rename 'efi' key to 'uki' in BLSConfig

Key 'uki' is more appropriate for us as the PE Binary that the key
points to is a UKI

[gemini-code-assist]

Code Review

This pull request introduces two main changes. First, it refactors the boot configuration logic by renaming efi and NonEFI components to uki and NonUKI respectively, which more accurately reflects that these are Unified Kernel Images. This change is applied consistently across several files, including configuration parsing, boot setup, and deletion logic. Second, it changes the installation of UKI addons to be global by default, installing them into a shared directory on the ESP rather than scoping them to a specific deployment.

My review focuses on the correctness and maintainability of these changes. The refactoring appears to be well-executed. However, I have identified a couple of potential issues with the new global addon functionality. One concern is that the logic for global addons might unintentionally alter the installation path for UKIs that are located in subdirectories. Another point is the lack of a deletion mechanism for these new globally installed addons, which could lead to orphaned files on the EFI System Partition. I've added specific comments with details on these points.

[cgwalters]

usecases like ignition, luks (for now at least), require the addons
to be applied to all deployments

FTR we covered some of this in coreos/fedora-coreos-tracker#2060

It feels a bit weird to install global addons from a container image by default; at least not without making that opt-in somehow.

Since as discussed the Ignition platform ID UKI addon needs to live "out of band" of the container, how about just adding bootc install --global-uki-addon=/path/to/file? (it might also make sense to support fetching them as an OCI artifact or so too)

Or really I guess in the CoreOS case since it's always using osbuild which always uses install-to-filesystem it could be the build process there that drops in the UKI addon for the platform ID right?

---

Overall my inclination is to back out on the UKI addon support in bootc for now and just do external dropins per above until we're sure we need in-band addons.

[Johan-Liebert1]

It feels a bit weird to install global addons from a container image by default; at least not without making that opt-in somehow.

Installing addons is opt-in using the --uki-addon flag. Until now they were installed specific to a deployment, which is a niche use case as people would want to install most addons globally for all deployments. @travier and I had a discussion on whether most addons would be scoped and global. There are some use cases for scoped addons, example for testing something before applying it to all deployments.

The platform ID Ignition addon is a special case and would most probably be not in a container (even though it very well could be in a container).