Remove note about federation tester not working with TLS 1.3

Fix wrong links in mautrix-signal docs

Allow psql args to be given to matrix-postgres-cli

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.

Clarify hosts file wording

Self-hosted Etherpad

Update IRC bridge to 0.23.0

Add double quotes 'matrix-postgres-init-additional-db-user-and-role.sql.j2' template

Fixed missing quotes

Use Debian Buster Docker repo on Debian Bullseye

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

Add mx-puppet-skype and mx-puppet-slack to README

I also moved matrix-sms-bridge up to match the order from container-images.md

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

Name the Synapse database on state compression import

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.

Correct some typos in FAQ

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