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`).

It should be `/bin/mkdir` and `/bin/chown` on Ubuntu 18.04 for example.
Still, it doesn't seem like we need to create and chown these
directories at all, since the playbook takes care of creating them
and setting appropriate permission by itself.

Regression since 67a445a74a

It used to allow user to logging with their own account to the bot
see: https://github.com/tulir/mautrix-telegram/wiki/Authentication#replacing-telegram-accounts-matrix-puppet-with-matrix-account
for more informations

We skipped v0.33.6 because of matrix-org/synapse#4014,
but v0.33.7rc2 fixed the problem.

Coturn reports it as an option that conflicts with `use-auth-secret`.
Some reasoning is here: fa523e8d09

`--log-driver=none` is used for all Docker containers now.

All these containers are started through systemd anyway and get logged in journald,
so there's no need for Docker to be logging the same thing using the default `json-file` driver.
Doing that was growing `/var/lib/docker/containers/..` infinitely until service/container restart.

As a result of this, things like `docker logs matrix-synapse` won't work anymore.
`journalctl -u matrix-synapse` is how one can see the logs.

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

I've found the previous 10K default value to be way too low
on a bunch of servers I'm running, so it's now up to
100K and made configurable.

Closes Github issue #5

Closes Github issue #3

Regression since a302a7d7489ec,
which made the Matrix Client API only available on
the http port (8008) and not over the federation port (8448).

This disables federation on the 80 port, as it's
not necessary. We also disable the old Angular webclient.

For the federation port (8448), we disable the client APIs
as those are not necessary. Those can even cause trouble
if one doesn't know about them and thinks that guarding the client
APIs at the 80 port is enough.

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)

This playbook does not set up guest access in Synapse anyway,
so until the need comes (or someone asks for it), guest access
is removed from riot-web's UI too.

As for supporting custom URLs, this is also not something
that seems like it'd be useful to most deployments.

It's not really a requirement, as it can function without it.
Also, restarting matrix-coturn doesn't need to restart matrix-synapse.

This playbook just tries to avoid trying to setup a Postgres 10
database with existing 9.x files, as that makes Postgres complain.

Due to this, existing installs (still on 9.x) are detected
and left on Postgres 9.x.
They need to be upgraded to Postgres 10.x manually.

Switching from from avhost/docker-matrix (silviof/docker-matrix)
to matrixdotorg/synapse.

The avhost/docker-matrix (silviof/docker-matrix) image used to bundle
in the coturn STUN/TURN server, so as part of the move,
we're separating this to a separately-ran service
(matrix-coturn.service, powered by instrumentisto/coturn-docker-image)