This change causes Nexus to populate external DNS names for each Silo's console/API endpoint, as determined in RFD 357. This includes some generic infrastructure in the datastore for constructing an update to the DNS configuration, plus a bunch of closely related changes:

• The test suite, omicron-dev run-all, and the "how-to-run-simulated" instructions all start up an external DNS server now.
• The DNS server now has support for A records (since external addresses can be IPv4 addresses).
• Authz for DNS operations now uses a synthetic resource for the global DnsConfig (rather than having various authz checks bake in that you need specific permissions on the Fleet).
• The test suite and simulated sled agent, which are both responsible for initializing the rack as RSS, now include the "Nexus" service and External DNS service during rack initialization. This is important so that Nexus's external IP gets recorded in the database, in turn so that it can be filled into each Silo's external DNS name.
  • As a consequence, the default Nexus config now listens on IPv6 loopback for the internal API rather than the IPv4 loopback. (The database configuration only supports v6 addresses for internal services.)
  • As another consequence, these pieces now include with rack initialization an internal service IP pool containing 127.0.0.1. This is a little funny and may need to be revisited. But right now, this does reflect what's already happening, and I don't think there's a better way to do this given the way the underlying pieces work today (which is that they assume Nexus's external addresses come from this pool).
• The name of the DNS zone being delegated to the rack now comes in during rack initialization. It used to be hardcoded inside Nexus. (It's still hardcoded, but now that's in the various places we do rack initialization, and they all use one definition.) This was to avoid hardcoding the value in multiple places inside Nexus, given that the eventual plan is for this to come from the user.

One caveat: this does not generate names for the built-in Silo because that doesn't go through the normal silo-create path. That Silo should be removed by the time we're ready to ship so I didn't think it was worth adding one-off code to support it.