brittle interface between Omicron and manufacturing

Background: https://github.com/oxidecomputer/mfg-troubleshooting/issues/1581, https://github.com/oxidecomputer/facade/pull/777

As I understand it:

• During the manufacturing process, the manufacturing software facade needs information from the rack.
• To get this, it invokes the wicket CLI with rack-update status --json. This tool:
  • reaches out to wicketd (one of our usual HTTP/JSON APIs -- an internal-only, lockstep one) to fetch the information
  • serializes the whole response to JSON and sends it to the client (facade)
• Facade uses wicket-common, an internal crate, to parse the result.

The CLI's --json output needs to be a stable API. Things should fail loudly at CI-time, if not compile-time, when it changes. But this implementation means any time this internal API changes, the stable API will be changed, too. That's the problem. There are a few potential solutions.

Option 1 is to make the commissioning API itself (or a read-only version of it) available externally and have facade use that. This seems directionally aligned with the purpose of the commissioning API. However, there are a bunch of questions about security here. (Does it need to be a new, read-only API? Does it need some other kind of authn/authz?)

Option 2 is more straightforward:

• Change the CLI implementation to use the commissioning API to fetch the information and serialize that for the client.
• Change facade so that instead of using wicket-common, it uses a Progenitor client for the commissioning API to parse the output of the rack-update status command. (I'm imagining it would get this Progenitor crate from Omicron, but I'm less positive about that.)

This way, we can leverage existing server-side-versioned tooling to evolve the commissioning API without breaking facade.