Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>

Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>

The spec had gotten updated

In nginx reverse-proxy, when the upstream server relies on SNI, the reverser-proxy may return 502 by follow error:
```
*10 SSL_do_handshake() failed (SSL: error:0A000410:SSL routines::sslv3 alert handshake failure:SSL alert number 40) while SSL handshaking to upstream, client: 172.19.0.1, server: example.host, request: "GET /.well-known/matrix/client HTTP/2.0", upstream: "https://<ip>/.well-known/matrix/client", host: "<domain>"
```
This problem often arises when the upstream server is behind the CDN, setting `proxy_ssl_server_name` to `on` will solve it.

the word "both" would refer to only 2 urls in this context

Make use of `example.com` more consistent (replace `DOMAIN`) and simplify Caddy 2 config. Remove Caddy 1 config since Caddy 1 is long past EOL.

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/1931

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/1931

This does 2 things:

- it fixes the syntax for `matrix_id`. Starting strings with `@` is
  invalid YAML, so such strings need to be wrapped in single or double
  quotes
- it makes use of the `matrix_domain` variable instead of hardcoding the
  domain name. This should be more and mistake-proof (typos or people
  mistaking their domain - matrix. vs base domain)

* Implement MSC 1929 Homeserver Admin Contact
Fixes #1612

For details to the proposed (not accepted yet) MSC, see:
https://github.com/matrix-org/matrix-spec-proposals/blob/hs/proposal-admin-contact-1/proposals/1929-admin-contact.md

* Implement feedback from PR #1931

* Implement feedback from PR #1931

* Fix mixed indentation

Fixes #586 (Github Issue)

Fixes #545 (Github Issue).

Adjust params

With most people on Synapse v0.99+ and Synapse v1.0 now available,
we should no longer try to be backward compatible with Synapse 0.34,
because this just complicates the instructions for no good reason.

Hopefully, we no longer lead people to believe that DNS SRV
records are going away forever and for all use-cases.

Fixes #156 (Github Issue)

This is provoked by Github issue #46.

No client had made use of the well-known mechanism
so far, so the set up performed by this playbook was not tested
and turned out to be a little deficient.

Even though /.well-known/matrix/client is usually requested with a
simple request (no preflight), it's still considered cross-origin
and [CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS)
applies. Thus, the file always needs to be served with the appropriate
`Access-Control-Allow-Origin` header.

Github issue #46 attempts to fix it at the "reverse-proxying" layer,
which may work, but would need to be done for every server.
It's better if it's done "upstream", so that all reverse-proxy
configurations can benefit.