Platform-agnostic host metadata for early-boot-config and pluto

[zmrow]

Problem

early-boot-config and pluto use IMDS directly. In order to start testing Bottlerocket on other platforms, these services must retrieve metadata and user data from other sources.

Proposed Solution

For the short term, we will extend early-boot-config for other platforms via the PlatformDataProvider trait provided in the program and conditionally compile it based on the variant. pluto will be similarly refactored and extended, adding additional arguments for other platforms if required. Doing so removes the first roadblock, allows us to begin testing on other platforms, and start gaining knowledge. While conditional compilation isn’t our favorite solution, the code can be factored out into a more unified solution should we find one in the future. Given the fact that there are only two first party Rust programs to extend makes this low risk and a two-way door.

Alternatives

Metadata translation service
This service would run on the Bottlerocket host and programs would call it rather than IMDS. It would translate any calls to the appropriate source for metadata. This is a compelling idea, but given how little we know about running Bottlerocket on other platforms, it feels a bit too early to commit to such a service. It is also yet another service to run at boot. The complexity it would add feels a bit unnecessary at this point.

One-shot program to query for all metadata
This idea is similar to the above metadata translation service, except it wouldn’t be a long running program. This program would run once at boot, query for the required metadata, and populate a file or data store with a commonly agreed upon format. Other programs would query this file or data store. This idea solves the issue of unifying the logic for querying various metadata services. However, it does raise a few problems of its own. This one-shot program must shape data in a format that other programs must agree on, which means a common and conditionally compiled library. We also would need to agree on a secure place to store this data. It is also another service to run on boot. Once again, the additional complexity doesn’t seem worth it for the short term.

Related to #968, #1097, #1114

[zmrow]

Closing this in favor of more specific issues. I opened #1369 to track some additional work for VMware for early-boot-config.

In regards to pluto we also have the option to write a new settings generator rather than extending pluto. Once we have a better idea of the settings we'll need, a separate issue will be opened.