* one var to control encryption across all bridges

* move var to matrix-base

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/2427

`metrics_enabled` should only expose the metrics locally, on the
container network, so that a local Prometheus can consume them.

Exposing them publicly should be done via a separate toggle (`metrics_proxying_enabled`).
This is how all other roles work, so this makes these mautrix roles consistent with the rest.

This paves the way for installing other roles into `roles/galaxy` using `ansible-galaxy`,
similar to how it's done in:

- https://github.com/spantaleev/gitea-docker-ansible-deploy
- https://github.com/spantaleev/nextcloud-docker-ansible-deploy

In the near future, we'll be removing a lot of the shared role code from here
and using upstream roles for it. Some of the core `matrix-*` roles have
already been extracted out into other reusable roles:

- https://github.com/devture/com.devture.ansible.role.postgres
- https://github.com/devture/com.devture.ansible.role.systemd_docker_base
- https://github.com/devture/com.devture.ansible.role.timesync
- https://github.com/devture/com.devture.ansible.role.vars_preserver
- https://github.com/devture/com.devture.ansible.role.playbook_runtime_messages
- https://github.com/devture/com.devture.ansible.role.playbook_help

We just need to migrate to those.

Not doing {% if matrix_admin %} checks in the YAML also fixes some issues
with indentation being incorrect sometimes.

This should be backward compatible, except for mautrix-signal's case
where `matrix_mautrix_signal_bridge_permissions` previously existed
as a string, not a dictionary. `tasks/validate_config.yml` will catch
the problem an even provide a quick fix.

Reference: https://ansible-lint.readthedocs.io/en/latest/default_rules/#git-latest

Our variable naming is not necessarily consistent across roles.
I've tried to follow the naming conventions of each individual role.
All new variables are suffixed with `_version`, but the prefix may be
somewhat different.

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

Previously, when matrix-postgres was disabled, we were setting
`matrix_mautrix_twitter_database_engine` to an invalid empty value.

Now, we always hardcode `matrix_mautrix_twitter_database_engine: postgres`,
but set/unset the database hostname and password values instead.

Signed-off-by: Aaron Raimist <aaron@raim.ist>

Remove references to sqlite since we should just use postgres from the
outset.

Updates based off the variable names used in mautrix-facebook role.

Also update port number in defauts/main.yml, and disable presence
checking, because Twitter doesn't support that.

find roles/matrix-bridge-mautrix-twitter -type f -exec sed -i \
  -e 's/facebook/twitter/g' \
  -e 's/Facebook/Twitter/g' \
  -e 's/FB/Twitter/g' \
  -e 's/fb/twitter/g' {} +

The Github link is just a redirect to Tulir's own GitLab, so I replaced the self-build link
The docker container repository was rearranged hierarchically (dock.mau.dev/tulir/mautrix-facebook -> dock.mau.dev/mautrix/facebook)
Tagged versions have been made available, thus :latest -> :v0.3.1

This adds https://github.com/matrix-org/matrix-doc/pull/2409 to the
appservice registrations, enabling synapse to push EDUs to appservices.

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

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

The `mobile` branch got merged to `master`, which ends up becoming
`:latest`. It's a "rewrite" of the bridge's backend and only
supports a Postgres database.

We'd like to go back (well, forward) to `:latest`, but that will take
a little longer, because:
- we need to handle and document things for people still on SQLite
(especially those with external Postgres, who are likely on SQLite for
bridges)
- I'd rather test the new builds (and migration) a bit before
releasing it to others and possibly breaking their bridge

Brave ones who are already using the bridge with Postgres
can jump on `:latest` and report their experience.

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 makes the `sqlite://` URI match what we were using before
and what the config expects.

Looks like there are some that I missed in 087dbe4ddc

I was thinking that it makes sense to be more specific,
and using `_postgres_` also separated these variables
from the `_database_` variables that ended up in bridge configuration.

However, @jdreichmann makes a good point
(https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/740#discussion_r542281102)
that we don't need to be so specific and can allow for other engines (like MySQL) to use these variables.

Regression since 2d99ade72f and 9bf8ce878e94, respectively.

When SQLite is to be used, these bridges expect an `sqlite://`
connection string, and not a plain file name (path), like Appservice
Discord and mautrix-whatsapp do.

This also disables presence if it's disabled for Synapse.

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

This patch makes us use more fully-qualified container image names
(either prefixed with docker.io/ or with localhost/).

The latter happens when self-building is enabled.

We've recently had issues where if an image was removed manually
and the service was restarted (making `docker run` fetch it from Docker Hub, etc.),
we'd end up with a pulled image, even though we're aiming for a self-built one.
Re-running the playbook would then not do a rebuild, because:
- the image with that name already exists (even though it's something
else)
- we sometimes had conditional logic where we'd build only if the git
repo changed

By explicitly changing the name of the images (prefixing with localhost/),
we avoid such confusion and the possibility that we'd automatically pul something
which is not what we expect.

Also, I've removed that condition where building would happen on git
changes only. We now always build (unless an image with that name
already exists). We just force-build when the git repo changes.