Initial attempt. Seems to work fine.

Only tested on debian amd64 so far

This will make data migration easier.

https://github.com/vector-im/element-web/releases/tag/v1.7.20
https://hub.docker.com/layers/vectorim/element-web/v1.7.20/images/sha256-44cae3a532d86c16940deb70866b522ba6acc8c5d7adf3c661cfc8b06f1de681?context=explore

This passes any arguments given to 'matrix-postgres-cli' to the 'psql' command.

Examples:
  $ # start an interactive shell connected to a given db
  $ sudo matrix-postgres-cli -d synapse
  $ # run a query, non-interactively
  $ sudo matrix-postgres-cli -d synapse -c 'SELECT group_id FROM groups;'

If they do, our next playbook runs would simply revert it
and report "changed" for that task.

There's no benefit to letting the bridge spew a new config file.

This does not apply to the mautrix whatsapp bridge, because that one
is written in Go (not Python) and takes different flags. There's no
equivalent flag there.

Future maintainer: check on https://docs.docker.com/engine/install/debian/ if Docker for
Debian 11 is released, then undo this commit

Fixes:
https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/833

The default scalar.vector.im integrations manager doesn't support custom
URL's for etherpad, therefore Dimension needs to be enabled.

Regression since f6097fbba1

Fixes a regression introduced in f6097fbba1fb, which was cauing Synapse
to die with this error message:

> ValueError: sender_localpart needs characters which are not URL encoded.

Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/806

These are just defensive cleanup tasks that we run.
In the good case, there's nothing to kill or remove, so they trigger an
error like this:

> Error response from daemon: Cannot kill container: something: No such container: something

and:

> Error: No such container: something

People often ask us if this is a problem, so instead of always having to
answer with "no, this is to be expected", we'd rather eliminate it now
and make logs cleaner.

In the event that:
- a container is really stuck and needs cleanup using kill/rm
- and cleanup fails, and we fail to report it because of error
suppression (`2>/dev/null`)

.. we'd still get an error when launching ("container name already in use .."),
so it shouldn't be too hard to investigate.

I don't think this was causing an issue, but it might
if the bot token has a more special value in the future.

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/828

This needs to be added for WebSocket upgrades to work properly (see doc:
http://nginx.org/en/docs/http/websocket.html)

Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/824

Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/823

Some people run Coturn or Jitsi, etc., by themselves and disable it
in the playbook.

Because the playbook is trying to be nice and clean up after itself,
it was deleting these Docker images.

However, people wish to pull and use them separately and would rather
they don't get deleted.

We could make this configurable for the sake of this special case, but
it's simpler to just avoid deleting these images.
It's not like this "cleaning things up" thing works anyway.
As time goes on, the playbook gets updated with newer image tags
and we leave so many images behind. If one doesn't run
`docker system prune -a` manually once in a while, they'd get swamped
with images anyway. Whether we leave a few images behind due to the lack
of this cleanup now is pretty much irrelevant.

Fixes a regression introduced in 95346f3117.

Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/814

Using `matrix_synapse_` variables in the `matrix-postgres` role is not
ideal, but.. this script belongs neither here, nor there.
We'll have it be like that for now.

The git module will create it anyway, but that would likely use `root:root`.

We log everything in systemd/journald for every service already,
so there's no need for double-logging, bridges rotating log files
manually and other such nonsense.

Well, they still do go to that DB by default,
but our docs give a better command to users, which would do the right
thing.

In short, this makes Synapse a 2nd class citizen,
preparing for a future where it's just one-of-many homeserver software
options.

We also no longer have a default Postgres superuser password,
which improves security.

The changelog explains more as to why this was done
and how to proceed from here.

I had intentionally held it back in 39ea3496a4
until:
- it received more testing (there were a few bugs during the
migration, but now it seems OK)
- this migration guide was written