Tracking issue for customer DNS

This issue tracks a few related to DNS provided to customers. This is generally laid out in RFD 21. Briefly, the ultimate goal is that the only DNS server provided to guests is the address we've reserved for it in each VPC Subnet, the third address in the subnet, e.g. 192.168.1.2 or fd12:3456::2. All DNS resolutions will go through OPTE, which will eventually intercept these and pass them on to the control plane in a TBD manner for resolution.

What happens next depends on the name being resolved. For an internal DNS name, e.g., inst-name.az-name.inst.vpc-name.project-name.org-name.internal, we need to resolve this by finding the primary VPC-private IP address for that instance. For an external name, e.g., inst-name.az-name.inst.vpc-name.project-name.org-name.oxide.acme.com, we need to resolve this by returning an external IP address, either Ephemeral or Floating, assigned to that instance. Same goes for resolution of Floating IPs directly. For any other request, we need to recursively resolve that by querying a DNS server that the customer needs to tell us about at rack setup time.

There's another aspect to DNS we need to provide, which is resolving requests for external IP addresses to clients outside the Oxide rack. This is a bit more straightforward. We need an API for the customer to tell us which address from an IP Pool we want that server to listen on, but it's otherwise "just" a normal server that resolves external names (e.g., inst-name.az-name.inst.vpc-name.project-name.org-name.oxide.acme.com) to the external IP address for that object. There may also be value in creating a Nexus HTTP API for making the same request too, I'm not sure.

Start with the DNS section of RFD 21 and trace the OPTE/control-plane boundary described in the issue. No files or tests are named; first turn the guest resolution, external resolution, and customer-configured upstream requirements into concrete deliverables, with completion defined by explicit behavior for each request type.