Host configuration resources for pooled DSS instances

[BenjaminPelletier]

Is your feature request related to a problem? Please describe.
To execute pooling actions, our setup and pooling procedures have instructions like "Reach out to existing operators to request their public cert," "share your CRDB node addresses with the operators of the existing DSS instances," and "The joining USS will also need a list of node addresses to which they should connect." These steps require DSS instance operators to exchange information out-of-band and the security and authenticity of this information exchange depends on the nature of that out-of-bad communication. The out-of-band communication is also usually manual, and therefore subject to substantial delays.

Describe the solution you'd like
Enable exchange of this information automatically by having a DSS instance publish its configuration information in a well-known location. After this is implemented, the only piece of information that would need to be exchange out-of-band would be the base URL of each DSS instance (existing and new, when pooling). This would enable the following automated equivalents when existing operators indicate their DSS instance base URLs as https://dss.uss1.example.com and https://dss.uss2.example.com, and a new USS joining the pool indicates their DSS instance base URL as https://dss.uss3.example.com:

"Reach out to existing operators to request their public cert"
--> GET https://dss.uss1.example.com/configuration/individual_ca.crt (and also for https://dss.uss2.example.com/configuration/individual_ca.crt)

"share your CRDB node addresses with the operators of the existing DSS instances"
--> GET https://dss.uss3.example.com/configuration/interface.json

{
  "crdb_node_addresses": [
    "0.db.dss.uss3.example.com",
    "1.db.dss.uss3.example.com",
    "2.db.dss.uss3.example.com"
  ],
  ...
}

"The joining USS will also need a list of node addresses to which they should connect."
--> GET https://dss.uss1.example.com/configuration/interface.json (and also for https://dss.uss2.example.com/configuration/interface.json)

The configuration endpoints would likely be protected by access tokens similar to existing access tokens, but with a scope of (for instance) interuss.dss_host.

At some future point (beyond this Issue), we could potentially introduce an endpoint like POST https://dss.uss1.example.com/configuration/refresh (redirecting to a status page of https://dss.uss1.example.com/configuration/referesh/{request_id}) which would cause USS 1 to reach out to all trusted peer DSS instances for their current configurations and make changes accordingly (e.g., CA certificates, CRDB node addresses). This would support automatic key rotation for the CA certs that authorize DSS instance synchronization, for instance.

Describe alternatives you've considered
There are many alternatives for custom PKI to exchange public certificates involving various forms of encryption and/or signing. However, it seems like we can achieve a high degree of simplicity by leveraging the standard public Internet PKI system for everything except communicating a trusted base URL controlled by the trusted party.

Additional context
This change may help to bring security of certificate and external-instance configuration information into InterUSS scope and thereby simplify security certifications for users since they will be able to point to this secure mechanism of exchanging this information.