It's good policy to use ansible vault to define passwords. However, due to an Ansible bug, to_json will not cause the password to be decrypted: https://github.com/ansible/ansible/issues/24425

The Server spec says that redirects should be followed for
`/.well-known/matrix/server`. So we follow them.

The Client-Server specs doesn't mention redirects, so we don't
follow redirects there.

Using `docker_container` with a `cap_drop` argument requires
Ansible >=2.7.

We want to support older versions too (2.4), so we either need to
stop invoking it with `cap_drop` (insecure), or just stop using
the module altogether.

Since it was suffering from other bugs too (not deleting containers
on failure), we've decided to remove `docker_container` usage completely.

Some resources shouldn't be cached right now,
as per https://github.com/vector-im/riot-web/pull/8702

(note all of the suggestions from that pull request were applied,
because some of them do not seem relevant - no such files)

Fixes #98 (Github Issue)

It's not important for us, as it only contains
some ACME-related fix.

`matrix_synapse_no_tls` is now implicit, so we've gotten rid of it.

The `homeserver.yaml.j2` template has been synchronized with the
configuration generated by Synapse v0.99.1 (some new options
are present, etc.)

This reverts commit 536c85619f.

Looks like binding metrics on IPv6 (`::`) fails with an error:

socket.gaierror: [Errno -2] Name does not resolve

We had something like that on the Server Delegation how-to page,
but it's better if we have it on the SSL certificates page.

Relocated there and improved linking.

Fixes #94 (Github Issue)

We don't provide certificates, so it fails anyway,
but we'd rather suppress the warnings about it too.

For consistency with all our other listeners,
we make this one bind on the `::` address too
(both IPv4 and IPv6).

Additional details are in #91 (Github Pull Request).

Add Synapse v0.99 support

People who wish to rely on SRV records can prevent
the `/.well-known/matrix/server` file from being generated
(and thus, served.. which causes trouble).

If someone decides to not use `/.well-known/matrix/server` and only
relies on SRV records, then they would need to serve tcp/8448 using
a certificate for the base domain (not for the matrix) domain.

Until now, they could do that by giving the certificate to Synapse
and setting it terminate TLS. That makes swapping certificates
more annoying (Synapse requires a restart to re-read certificates),
so it's better if we can support it via matrix-nginx-proxy.

Mounting certificates (or any other file) into the matrix-nginx-proxy container
can be done with `matrix_nginx_proxy_container_additional_volumes`,
introduced in 96afbbb5a.

Regression since 96afbbb5af

Certain use-cases may require that people mount additional files
into the matrix-nginx-proxy container. Similarly to how we do it
for Synapse, we are introducing a new variable that makes this
possible (`matrix_nginx_proxy_container_additional_volumes`).

This makes the htpasswd file for Synapse Metrics (introduced in #86,
Github Pull Request) to also perform mounting using this new mechanism.
Hopefully, for such an "extension", keeping htpasswd file-creation and
volume definition in the same place (the tasks file) is better.

All other major volumes' mounting mechanism remains the same (explicit
mounting).

Continuation of 1f0cc92b33.

As an explanation for the problem:
when saying `localhost` on the host, it sometimes gets resolved to `::1`
and sometimes to `127.0.0.1`. On the unfortunate occassions that
it gets resolved to `::1`, the container won't be able to serve the
request, because Docker containers don't have IPv6 enabled by default.

To avoid this problem, we simply prevent any lookups from happening
and explicitly use `127.0.0.1`.