some of reconfigurator-cli's sled state management is error-prone and not faithful to real systems #11592

These probably could be separate issues but they may relate so for now I'm just writing them down in one place.

While working on RFD 747 and exploring the "sled add" behavior (see this comment), I ran into several paper cuts.

1. It'd be nice to have commands like these that would avoid having to hardcode a bunch of stuff like in the linked comment:

sled-update-sp SERIAL --to-target-release
sled-update-rot SERIAL --to-target-release
sled-update-rot-bootloader SERIAL --to-target-release
sled-update-host-phase1 SERIAL --to-target-release

2. A command like sled-set-all --to-target-release (or something) would be a handy one-shot command to make everything on a sled match what Reconfigurator would do. That would trim a lot of the preamble in reconfigurator-cli: reduce boilerplate for tests that want to simulate an update #11403 -- you'd run this command for each sled instead of all those specific commands.

3. A command like this:

sled-mupdate SERIAL --to-initial | --to-target-release

could do what a MUPdate generally does:

• set the mupdate override flag with a new value
• set all the components (SP, RoT, RoT bootloader, host phase 1/2, zones, and measurements) to some canned values

I wanted this for testing the "add sled" case (where a sled shows up MUPdated) and I expect it would simplify the MUPdate tests, though we'd want to verify that it would work for those. On the other hand, if we do the next item, we probably wouldn't use this for the "sled add" case.

4. It would be good to verify (or else ensure) that the initial state you get from load-example and sled-add accurately reflects the situation that they're trying to simulate. I think load-example should probably create a system that looks like it's just been RSS'd, but before Reconfigurator has run. That would include all the zones deployed like today, but would have MUPdate overrides set (I think). sled-add should similarly look like a just-MUPdated sled. In both cases, I think we'd expect that running sled-mupdate --to-initial would change nothing.

I'm not sure if this will impact a lot of tests, but it seems worth it to be more realistic. It may end up simplifying a lot.