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

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

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

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.

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.

It was trying to omit the `-a` flag, but that wasn't enough,
because the underlying `register_new_matrix_user` command
prompts interactively if it doesn't see the `-a` flag
(it doesn't default to non-admin).

We need to answer such interactive prompts.