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.

Related to #451 (Github Issue).

This keeps the roles cleaner and more independent of matrix-base,
which may be important for people building their own playbook
out of the individual roles and not using the matrix-base role.

I've been thinking of doing before, but haven't.

Now that the Whatsapp bridge does it (since 4797469383),
it makes sense to do it for all other bridges as well.
(Except for the IRC bridge - that one manages most of registration.yaml by itself)