[wicketd] allow starting multiple updates with one API call

[sunshowers]

Extend post_start_update to allow starting updates on several sleds at
once. This is not currently used (the TUI always updates one sled at a
time), but will be used for command-line driven mupdates.

If we're issuing updates on several sleds at once, we can encounter
different kinds of errors for each sled. So instead of returning
immediately, we collect errors into a vector and then return them all at
once.

This also required some refactoring in update_tracker.rs. To take care
of all possible situations:

1. Add a new SpawnUpdateDriver trait, which has two methods: one
   to perform a one-time setup, and one to perform a spawn operation for
   each SP.
2. Add three implementations of SpawnUpdateDriver:
   RealUpdateDriver which is the actual implementation,
   FakeUpdateDriver which is used for tests, and NeverUpdateDriver
   which is an uninhabited type (empty enum, can never be constructed)
   and is used to perform pre-update checks but not the update itself.

Happy to hear suggestions about how to make this better.

One path I went down but rejected is using a typestate to indicate that
update checks had passed -- then the caller could decide whether to
perform the update or not. The problem is that for the typestate to be
valid it would have to hold on to the MutexGuard (otherwise something
could come in between and replace the task that we thought was
finished), and that seems a bit fraught as you could accidentally
attempt to lock the update data again. A callback-like approach, which
was the previous implementation and which has been retained in this PR,
does not have that pitfall.

I tested this by spinning up sp-sim, mgs, and wicketd, and it worked
as expected. Errors (e.g. no inventory present) were caught as
expected.

[jgallagher]

LGTM! 👍

[jgallagher]

Tiny nit since the list refers to single SPs:

Suggested change

	// Can we update the target SPs? We refuse to update if:
	// Can we update the target SPs? We refuse to update if for any target SP:

[sunshowers]

Done, thanks!

[jgallagher]

Tiny nit - could we move the let plan = ...; if plan.is_none() check from farther above to just before the if !errors.is_empty() check, just so it's easier to visually jump from this expect() to the place where we can see it's correct?

[sunshowers]

Also done, and added a comment to be clear about it.