This is described in Github issue #58.

Until now, we had the variable, but if you redefined it, you'd run
into multiple problems:

- we actually always mounted some "storage" directory to the Synapse
container. So if your media store is not there, you're out of luck

- homeserver.yaml always hardcoded the path to the media store,
as a directory called "media-store" inside the storage directory.

Relocating to outside the storage directory was out of the question.

Moreover, even if you had simply renamed the media store directory
(e.g. "media-store" -> "media_store"), it would have also caused trouble.

With this patch, we mount the media store's parent to the Synapse container.
This way, we don't care where the media store is (inside storage or
not). We also don't assume (anymore) that the final part of the path
is called "media-store" -- anything can be used.

The "storage" directory and variable (`matrix_synapse_storage_path`)
still remain for compatibility purposes. People who were previously
overriding `matrix_synapse_storage_path` can continue doing so
and their media store will be at the same place.

The playbook no longer explicitly creates the `matrix_synapse_storage_path` directory
though. It's not necessary. If the media store is specified to be within it, it will
get created when the media store directory is created by the playbook.

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.