wicket should be able to update the scrimlet in a single sidecar environment

At present, it does not appear to be possible to use wicket to perform a mupdate of an entire environment when there is only one sidecar: wicket cannot coordinate update of the scrimlet upon which it is executing, so the user must perform some out-of-band manual update of at least the host OS image there.

In the past, a hard limit on improving this situation has been that while the scrimlet is online (in the A0 state) it has not been possible to update the host OS ROM image over the management network. Taking the scrimlet down to A2 means that wicket (and indeed all host OS software!) is obviously not executing any longer.

As of oxidecomputer/hubris#1575 and oxidecomputer/hubris#1172 it is now actually possible to update the host OS ROM while a system is in A0, provided it is not currently booting. The first IPCC message sent from the host OS to the SP causes the SP to detach the host OS ROM, making it available for updates again (in A0!) as it would be in the A2 state.

There is still the question of what to do about the fact that mupdate is driven by a user with an SSH connection to the switch zone, but I suspect what we'd want to do is roughly:

• line up all of the ducks on other sleds that need updating, then get the M.2 disk image deployed on the scrimlet
• get the host OS ROM updated on the scrimlet over the management network
• tell the user something to the effect of "it's now safe to turn off your computer" and potentially gracefully end the SSH connection and kick off a reboot
• the user would dutifully wait a number of minutes and then be able to SSH back in to the freshly updated and rebooted switch zone

Start by reading the behavior described here and the referenced oxidecomputer/hubris#1575 and #1172 changes. Trace how mupdate currently coordinates other sleds and how the single-sidecar SSH session is handled. Done means a full environment update can deploy the M.2 image, update the scrimlet host OS ROM, safely end or warn about the SSH session, and reboot so the user can reconnect.