container: Cache new manifest/config in prepare, add API to query

[cgwalters]

Closes: #496

In coreos/rpm-ostree#4486 we were working on fixing rpm-ostree upgrade --check with containers.

However, what we really want here is to persist the updated manifest (and config) that we fetch. And if we do that, we might as well just make it part of the current prepare() API so it happens automatically.

In this change, we do so via detached commit metadata. An important thing here is that the data is then automatically lifecycle bound to the merge commit - and the merge commit always changes when we fetch a new manifest.

In order to do an offline query (e.g. in rpm-ostree we want to re-synthesize a higher level summary of the queued update) add an API which allows querying a previously saved cached update.

Hence a flow like this should work:

• OS boots
• OS updater does a background "check for updates" via calling prepare()
• OS updater finds an update, and renders metadata to the user or orchestration system
• <time passes; OS update is not downloaded - e.g. user is on metered data or whatever>
• system reboots for other reasons
• OS updater can re-render the fact that a queued update was found without touching the network
• User can initiate a full fetch (e.g. including image layers) targeting exactly the previously prepared fetch. This makes things much more race-free; if the image was GC'd in the meantime we correctly fail.

[cgwalters]

OK, I think this is probably good...still doing some further testing with rpm-ostree but I think I'm narrowing in on the last mile of bugs there.

[cgwalters]

Thinking about this a bit more, two potential issues:

• We don't offer a direct API to clear cached updates...not sure anyone will care, but I could imagine it
• This actually breaks the use case for just checking for updates from a read-only repository, but again, it's not really clear that's a real use case

[jmarrero]

Why not being able to check for updates from a read-only repo is an issue?
I assume once you rebase to it, you would need to rebase to another one to get new content right? (I am guessing that read-only means the contents of the repo will not change.)

[cgwalters]

The "read only repo" case happens to day on e.g. the FCOS Live ISO. You can do rpm-ostree status, but not rpm-ostree install e.g. Now...eventually we probably should make the repo (and everything else) transiently writable with an overlayfs just like etc but that's a separate ball of wax.

OK well, this doesn't work today (try with e.g. cosa run --qemu-iso fedora-coreos-latest-live.x86_64.iso):

$ rpm-ostree upgrade --check
error: Remounting /sysroot read-write: Permission denied

And so this won't be a regression.

[jmarrero]

As for "We don't offer a direct API to clear cached updates..."
If people can rm the files if needed, this lgtm.

[cgwalters]

Yeah, one can use the low level ostree API to clear detached metadata entirely at least.