Previously, it was more necessary to have it
(because we had a dependency between matrix-synapse and matrix-nginx-proxy)..
But nowadays, it can be removed without negative side effects.

Restarting matrix-nginx-proxy is especially bad when the proxy is not installed at all.

Fixes a problem where importing would lead to this error:
    Cannot link to /matrix-postgres, as it does not belond to the default network.

* Add default template file for homepage HTML
* Add default riot-web config options for homepage

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.

This makes it more consistent with other usage throughout the playbook.

This also raises the default from 5 seconds to 15 seconds.

Regression since 3fd6fd647f

Pretty much all variables live in their own `matrix_<whatever>`
prefix now and are grouped closer together in the default
variables file (`roles/matrix-server/defaults/main.yml`).

The setup-all should include the setup_well_known task as well

If a network like `matrix-whatever` already exists for some reason,
the `docker_network` module would not create our `matrix` network.
Working around it by avoiding `docker_network` and doing it manually.

Fixes Github issue #12

The old way is deprecated and would stop working
after Ansible 2.11.

If the playbook were to run with `--tags=setup-nginx-proxy`,
it wouldn't go into `setup_corporal.yml`, which meant it wouldn't
perform a bunch of `set_fact` calls which override important
nginx proxy configuration.

We run these variable overrides on each call now (tagged with `always`)
to avoid such problems in the future.

Fix typo
Move mautrix variable in `defaults/main.yml` exclusively

We've been using Goofys for a long time instead.

Moving away from using the default bridge network to using our own.
This isolates our services from other Docker containers running
on the default network on the same host.

The benefits are that:

- isolation is a little better - we no longer share a default
bridge network with any other containers that might be running on the host

- there are no longer hard dependencies - we do service discovery
by DNS name, and not via explicit `--link` usage during container start,
so containers can start out of order and fail without bringing down others
with them
(`matrix-nginx-proxy` can continue running, even if one of the other services dies)

In the future, when other services get introduced,
the increased resilience and simplicity will help as well.

Until now, we were starting from a fresh configuration, as generated
by Synapse and manipulating it with regex and line replacements,
until we made it work.

This is more fragile and less predictable, so we're moving to a static
configuration file generated from a Jinja template.

The upside is that configuration will be stable and predictable.

The downside of this new approach is that any manual configuration changes
after the playbook is done, will be thrown away on future playbook
invocations.

There are 2 ways to work around the need for manual configuration
changes though:
- making them part of this playbook and its default template
configuration files (which benefits everyone)
- going your own way for a given host and overriding the template files
that gets used (that is, the
`matrix_synapse_template_synapse_homeserver` or
`matrix_synapse_template_synapse_log` variables)