We try to only use console logging (going to journald) for everything,
instead of logging things twice (or more).

While it's kind of nice having it, it's also somewhat raw
and unnecessary.

Having a good default and not even mentioning it seems better
for most users.

People who need a more exposed bridge (rare) can use
override the default configuration using
`matrix_mautrix_signal_configuration_extension_yaml`.

The answer to these is: it's good to have them in both places.
The role defines the obvious things it depends on (not knowing
what setup it will find itself into), and then
`group_vars/matrix_servers` "extends" it based on everything else it
knows (the homeserver being Synapse, whether or not the internal
Postgres server is being used, etc.)

We used to store them in data/, but that seems inappropriate,
since it's just static configuration that the playbook can recreate.

Keeps up with a1f64f5159 (diff-0ccf69eb4d59a7645eb4d0a0b077e693948edb33ad06df043bba3fb30122879b)

We need to suppress systemd service-stopping requests in certain rare
cases like https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/771

That issue seems to describe a case, where a migration from mxisd to
ma1sd was happening (DB files had just been moved), and then we were
attemping to stop `matrix-ma1sd.service` so we could import that database into
Postgres. However, there's neither `matrix-mxisd.service`, nor
`matrix-ma1sd.service` after `migrate_mxisd.yml` had just run, so
stopping `matrix-ma1sd.service` was failing.

Fixes a problem like this:
> File "/usr/lib/python3.8/site-packages/mautrix/bridge/e2ee.py", line 79, in __init__
> raise RuntimeError("Unsupported database scheme")

mautrix-python's e2ee.py module expects to find `postgres://` instead of
`postgresql://`.

This is 8b6174786b done right. There were many more fields
that we had to account for.

This makes the `sqlite://` URI match what we were using before
and what the config expects.

Our old (base-path -> data-path) SQLite migration can't work otherwise.

It's probably not necessary to keep it anymore, but since we still do,
at least we should take care to ensure it works.

Should have been part of 149872e00c

This also adds support for installing python3-docker (not python-docker)
in systems that run Python 3.

Raspbian doesn't seem to support arm64, so this is somewhat pointless
right now.

However, they might in the future. Doing this should also unify us
some more with `setup_debian.yml` with the ultimate goal of
eliminating `setup_raspbian.yml`.

It's likely installed by default, but it doesn't hurt to specify it.
It also makes us more the same with `setup_debian.yml`.

Well, `ubuntu` or `debian`, the same key is served right now,
so it doesn't really matter.

This seems cleaner and less prone to breakage though.

Until now, we've only supported non-amd64 on Raspbian.

Seems like there are now people running Debian/Ubuntu on ARM,
so we were forcing them into amd64 Docker packages.

I've gotten a report that this change fixes support
for Ubuntu Server 20.04 on RPi 4B.

We were only defining this in `group_vars/matrix_servers`, which is
inconsistent with how we normally do things.

Revert "Correct inabillity for appservice-discord to connect"
This reverts commit 673e19f830.

While certain things do work even with such a local URL, sending
messages leads to an error like this:

> [DiscordBot] verbose: DiscordAPIError: Invalid Form Body
> avatar_url: Not a well formed URL.

Fixes https://github.com/Half-Shot/matrix-appservice-discord/issues/649

The sample configuration file for appservice-discord
c29cfc72f5/config/config.sample.yaml (L8)
explicitly says that we need a public URL.

Now that 0.7.2 is out, the Docker image supports Postgres
and we can do the (SQLite -> Postgres) migration.

I've also found out that we needed to fix up the `tokens.ex_date` column
data type a bit to prevent matrix-registration from raising exceptions
when comparing `datetime.now()` with `ex_date` coming from the database.

Example:

> File "/usr/local/lib/python3.8/site-packages/matrix_registration/tokens.py", line 58, in valid
> expired = self.ex_date < datetime.now()
> TypeError: can't compare offset-naive and offset-aware datetimes

In cases where pgloader is not enough and we need to do some additional
migration work after it, we can now use
`additional_psql_statements_list` and
`additional_psql_statements_db_name`.

This is to be used when migrating `matrix-registration`'s data at the
very least.