Discovery and registration of new rack and sleds in CRDB

Nexus must be able to learn of a new rack on the underlay network and register it as "unadopted" in CRDB.

The only services running on sleds in a new rack on the underlay network are sled-agents. In our current single rack system sled-agents upsert themselves to Nexus. While we could keep this path, I think it's a mistake. This is a client-side versioned API that makes managing versions difficult. It also directly inserts sleds into the sled-table. While we could also mark these unadopted in the existing sled table, it would probably be easier to manage things with a separate table of discovered and unadopted sleds.

The alternative to upserting is to have nexus discover new sled-agents and poll them for details. This would lead to a parallel path for RSS and MultirackJoin for the call to StartSledAgent. But that's fine. When joining new racks we already have a control plane up, and only need to bring up sled-agent in a "waiting" state.

The key problem here becomes how Nexus discovers new sled-agents. Sled-agents could attempt to publish themselves to DNS or use DDM based discovery. Their addresses should also be fairly predictable if the /56 for the new rack is known.