rot release

Tech port unlocking (simple version) (#1835)

This PR implements tech port unlocking, as described in [RFD
492](https://rfd.shared.oxide.computer/rfd/492). It corresponds to
https://github.com/oxidecomputer/management-gateway-service/pull/259 and
should be merged after that goes in.

There's a lot going on here, but it's tricky to split into smaller PRs,
so I'll describe the different moving pieces

## Changes to `net` VLANs
### Configuration
VLANs are no longer contiguous; instead, the configuration in the
manifest specifies them by VID. Each VLAN is also labelled as trusted or
untrusted, which changes the behavior of the `net` task. The mapping
from VLAN to port has become many-to-one, because Sidecar now has 3x
VLANs on `SpPort::One`.

### Runtime behavior
Packets to/from untrusted VLANs are dropped in the `net` task, unless
the destination task has `accept-untrusted = true` in its socket
configuration. This may be disabled for a limited time with the new
`Net.trust_vlan` Idol API.

## Monorail and KSZ8463 configuration changes
The VSC7448 (Monorail) and KSZ8463 switch have a new baseline
configuration: packets between VSC7448 port 48 (to the Sidecar-local SP)
and the KSZ8463 are now VLAN tagged per [this
scheme](https://rfd.shared.oxide.computer/rfd/492#_fully_tagged_packets_on_port_48).

In addition, the VSC7448 is now configured to disable access to SPs
(other than the Sidecar-local SP) from the tech port. This is
implemented in `configure_vlan_sidecar_locked`. The Monorail API now has
two new functions (`Monorail.unlock_vlans` and `Monorail.lock_vlans`) to
change this behavior.

## Changes to `control-plane-agent`
### General
Across all boards, `SpImpl` function signatures and implementations are
changed to use the new `Sender` type where appropriate.

### Sidecar
On the Sidecar, we implement tech port unlocking based on a `Trivial`
challenge, which calls into `monorail` and `net` to reconfigure them.