server: introduce a serial console backend

[gjcolombo]

Rework parts of propolis-server's serial console logic to achieve the following goals:

• Make the serial console history buffer (which is transferred in the live migration protocol) use the versioned payload helpers supplied by the main Propolis library.
• Provide the primitives necessary to implement the policies described in RFD 491: it should be possible to distinguish read-write and read-only clients of a serial console and apply different policies (around the number of clients and what happens if they fall behind when reading) to each of them.
• Simplify the logic for dealing with multiple serial console clients to avoid cancellation safety issues.

To do this, split the existing serial console task into two layers. The ConsoleBackend layer deals with I/O to and from a Propolis character device. The SerialConsoleManager layer creates a task for each websocket connection to a serial device and registers it as a client of the relevant ConsoleBackend. The backend layer allows the manager to declare that specific clients have read-only access to the console and to decide what happens if a client becomes unable to accept new bytes from a client; the manager implements the policies that determine how many clients can exist concurrently and what backend policies apply to them.

Update the serial API endpoint to allow users to request a writable connection to the console. Add parameters to the serial console helper types in propolis-client that govern how this is set. This will require a small update to Nexus the next time Omicron picks up a Propolis build to add the extra parameter. End users don't see this aspect of the serial API (Nexus serves as a proxy for connections to VMs' serial consoles), so this should be a non-breaking change for control plane API users.

propolis-cli serial defaults to a writable connection to match previous behavior, but it now supports a --readonly flag to create read-only connections.

As currently written, this PR implements the "only one read-write client at a time" policy described in RFD 491. I can easily disable this part of the change if we don't want to do this yet (should just need to remove a few lines from the console manager's client-attach function).

Tests: cargo test, PHD, ad hoc testing with local propolis-server processes. This change changes the order of messages sent in the migration protocol and so will break the migrate-from-base tests; this remains OK for now since live migration isn't being used in production yet.

Fixes #650. Related to #614.

[gjcolombo]

Thanks as always for the thorough review, @hawkw! I'm going to rebase this as-is onto #834 and then will start tightening things up.

[gjcolombo]

@hawkw: I think I've addressed all your feedback in the newest round of commits. The new changes use tokio::io::simplex (thank you for suggesting this!), but this required some architectural adjustments to account for differences between a WriteHalf and an mpsc::Sender (the former isn't Clone, and writes won't return an error if the reader is dropped). For the most part, what this amounts to is that the ConsoleBackend's read task no longer reads the backend's client table directly; instead the backend feeds it a set of Reader objects, and readers and their clients share a watch so they can mutually shut down without having to hold references to each other.

There's a new theory statement in serial/backend.rs that tries to explain this a bit more. Let me know what you think.