This has been tested and appears to work.

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.

The only one that remains is `matrix_synapse_database_password`, but
that's something old and should be dealt with separately in the future
(unless it remains as it is).

Related to 9bf8ce878e.

Should have been done during 2a99e84b5bfd9f39, but I've missed it.

Because of this, 9bf8ce878e was also incomplete and would have caused
an error.

`matrix_SERVICE_database_engine` remains as it is - the only one with a
`_database_` infix. Postgres-related ones move to `_postgres_`.

Using the result of `password_hash` works for creating them,
but authentication seems to be failing with some tools like pgloader.

It's possible that we're not escaping things properly somewhere.
Ideally, it'd be nice to solve that. But the easier (and still
relatively safe/good) solution is to just turn that password hash
into a UUID that's safe for passing around without worrying about
escaping.

People can toggle between them now. The playbook also defaults
to using SQLite if an external Postgres server is used.

Ideally, we'd be able to create databases/users in external Postgres
servers as well, but our initialization logic (and `docker run` command,
etc.) hardcode too many things right now.

Being more explicit sounds better.

Quotes are necessary around dictionary field names.

There was a missing `}` as well.

We'll most likely use one that matches the database name, but
it's better to have it configurable.

If a service is enabled, a database for it is created in postgres with a uniqque password. The service can then use this database for data storage instead of relying on sqlite.

ma1sd requires the openid endpoints for certain functionality.
Example: 90b2b5301c/src/main/java/io/kamax/mxisd/auth/AccountManager.java (L67-L99)

If federation is disabled, we still need to expose these openid APIs on the
federation port.

Previously, we were doing similar magic for Dimension.
As per its documentation, when running unfederated, one is to enable
the openid listener as well. As per their recommendation, people
are advised to do enable it on the Client-Server API port
and use the `federationUrl` variable to override where the federation
port is (making federation requests go to the Client-Server API).

Because ma1sd always uses the federation port (unless you do some
DNS overwriting magic using its configuration -- which we'd rather not
do), it's better if we just default to putting the `openid` listener
where it belongs - on the federation port.

With this commit, we retain the "automatically enable openid APIs" thing
we've been doing for Dimension, but move it to the federation port instead.
We also now do the same thing when ma1sd is enabled.

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

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

Similar to 12867e9f18a3321217083, but for `matrix-coturn` (not
`matrix-nginx-proxy`).

Related to #681 (Github Pull Request)

We'd like the roles to be self-contained (as much as possible).

Thus, the `matrix-nginx-proxy` shouldn't reference any variables from
other roles. Instead, we rely on injection via
`group_vars/matrix_servers`.

Related to #681 (Github Pull Request)

This reverts commit 7d211b71e2.

The multi-arch images are now available, as discussed in #699 (Github Issue).

Fixes #696 (Github Issue)

Regression since 63a49bb2dc.

Related to #685 (Github Issue).

We now automatically expose the APIs when Synapse Admin is enabled.

While v1.22.0 supposedly has multi-arch Docker images
(thanks to https://github.com/matrix-org/synapse/pull/7921),
I can't them on Docker Hub yet, so I'm backing out of this change
for now and letting people fall back to self-building there.

Related to #658 (Github Issue).

Fixes #562 (Github Issue)

Fixes #586 (Github Issue)

Signed-off-by: Tulir Asokan <tulir@maunium.net>

ma1sd 2.4.0 announced experimental support for arm64.
We're making use of those arm64 images instead of self-building.