add pending MGS-managed updates to blueprint

[davepacheco]

Like we did with zone images, this PR only contains updates to the in-memory representation. Database support and reconfigurator-cli support will come in a follow-on PR.

This is theoretically ready to go, but there's no rush yet as there's no consumer yet.

[davepacheco]

This PR reflects a work-in-progress that Jordan and I are doing separate work based off. This isn't set in stone yet but I wanted to document the plan here.

The idea is that the blueprint maintains a list of pending MGS-managed updates. An MGS-managed update is any update done by the SP and controlled via MGS, which means: RoT bootloader, RoT Hubris image, SP Hubris image, and host phase 1. There may be at most one of these pending for any baseboard at once, but there could be multiple baseboards getting an update at once. (A baseboard is a thing with an SP on it: Gimlet, Sidecar, or PSC.)

When the planner wants to update one of these things, it adds a PendingMgsUpdate to the (next) blueprint. When it notices that the inventory reflects that that change has been made, it removes it from the (next) blueprint.

I was initially reluctant about this approach because it sounds a little like "storing the steps", which we've explicitly avoided elsewhere with blueprints. It's not really, though, because it's not saying "you should perform this update next". It's saying what should be deployed -- just limiting what it's specifying to only the sleds it wants to take action on. (If we just stored the end state (the desired version of each thing), then during execution, we'd have to query everything in the system for its current version and check it against what the blueprint said we should have. That's duplicating all the work the planner literally just did. Further, that might cause us to do something different than the planner expected (what if when the planner made its decision, it was intending to update one sled; but now some other sled is also behind, and now we wind up resetting a sled unexpectedly -- yikes).)

[davepacheco]

This PR went up as a first step that @jordanhendricks and I could both work from. In my branch, I've had to diverge a fair bit. Other recent changes (moving stuff out of Omicron and into tufaceous) resulted in this PR needing more work just to keep up with "main". That seems like a waste of time at this point. I'm going to close this version for now. When I'm further along the other branch, I'll plan to split that into several smaller PRs, and the work here will be one of those.

[davepacheco]

I should add: the basic approach here hasn't changed. But a bunch of nitty details have, and those have created a bunch of make-work to keep in sync with both "main" and my branch.