Create an interface for determining the release date of an update

[cbgbt]

What I'd like:
I'd like to programmatically be able to associate an updated Bottlerocket image with the datestamp when it was published.

One possible approach to this would be to query the wave schedule information for an update from the TUF repository. Maybe this could be exposed via apiclient, e.g.:

$ apiclient update release-data $VERSION
{
    "version": "$VERSION",
    "waves": {
        // etc
    },
}

Any alternatives you've considered:

• Bottlerocket release information is also published to SSM via pubsys. Timestamp information could possibly be made available via SSM parameters for variants.

[cbgbt]

One edge case to consider in the design and implementation of this is how to handle the seed and ignore-waves settings.

For the sake of API consistency, an apiclient update interface should possibly have a host be unaware of an update image unless it has reached the appropriate wave. On the flip side, it would be a poor UX to have to enable ignore-waves to perform a metadata query. Maybe an --ignore-waves option to the command would be appropriate.

Alternatively, should apiclient update release-data always ignores waves, since it's a simple informational lookup?

[cbgbt]

I've been investigating the implementation of this feature. Just recording what I've been thinking:

I think the interface should be something like:

apiclient update describe --version 1.20.1 [--ignore-waves]

---

There are some implementation challenges that need to be considered. Currently the callpath of apiclient update is something like this:

apiclient -> apiserver -> thar-be-updates -> (fork) updog

This allows the single-threaded apiserver to remain unblocked while updog attempts to fetch and process the repository metadata.

The processed information is serialized to disk in the UPDATE_STATUS file. Subsequent calls to the apiserver use that file when handling GET requests.

Some problems:

• The UPDATE_STATUS file does not contain the repository metadata needed to handle a describe call -- it is laser-focused on providing actionable status information that can be used to drive Bottlerocket's update state machine correctly via the API.
• updog is currently responsible for handling "wave visibility" processing; however, we need this command to possibly subvert the system-defined wave visibility processing. Our work here may need to move this processing into a shared library to ensure the abstraction is upheld consistently.

---

Possible path forward:

1. Any updog whats command that involves a repository refresh could also emit the un-processed update metadata to an additional cache file.
2. Move visibility processing to a shared library so that the un-processed file can be successfully processed at the thar-be-update/apiserver level.