Proof of concept: support multiple domains on a single server.

[nicktobey]

This change allows the server to declare multiple domains that it is authoritative for, in addition to the base server name. Every listed domain must have its own well-known entry, pointing to the same REST API.

Clients will be able to use any of the supported domains as the homeserver name, and they all resolve to the same server. It's still a single server: for instance, it has a single room directory. But the server has the ability to authorize users from any of its supported domains.

Rationaille:

There are two use cases that immediately come to mind:

• An organization that wants a separate domain for staff vs users to reduce the risk of staff impersonation.
• Small homeservers that want to allow users to use a domain they control as a UserID.

The use of well-known already allows a Matrix server to be authoritative for a single domain that doesn't match the API domain: this change merely allows the server to be authoritative for multiple such domains.

Tests:

I added a basic test that the registration workflow works for alternate domains, but additional test coverage than this is probably required. Ideally we'd want to test that the server does not attempt to federate with itself or use the Server-Server API to resolve references to an alternate domain. But I couldn't find those kinds of integration tests in the codebase and wasn't sure how they should be added.

Risks:

I'm trying to think if alternate domains could violate any existing invariants. The big change is that it's now possible for IDs from two different domains to both be seen as "local", but I'm not sure if that can break anything.

It's possible that users on one domain might be able to create room aliases on the alternate domain. I'm not sure how room alias permissions work, and whether this is a problem.