- removed build_database_list.yml

- add matrix_postgres_backup_databases to be build on top of matrix_postgres_additional_databases
- POSTGRES_DB is now directly set from matrix_postgres_backup_databases while building the templates/env-postgres-backup.j2

- adjusted env-postgres-backup.j2 to use the new role specific variables

Self-checks against the .well-known URIs look for the HTTP header
"Access-Control-Allow-Origin" indicating that the remode endpoint
supports CORS. But the remote server is not required to include
said header in the response if the HTTP request does not include
the "Origin" header. This is in accordance with the specification
[1] stating: 'A CORS request is an HTTP request that includes an
"Origin" header.'

This is in fact true for Gitlab pages hosting and that's why the
issue was identified.

Let's specify "Origin" header in the respective uri tasks performing
the HTTP request and ensure a CORS request.

[1] https://fetch.spec.whatwg.org/#http-requests

We have a flow like this:
1. matrix.DOMAIN vhost (matrix-domain.conf)
2. matrix-synapse vhost (matrix-synapse.conf); or matrix-corporal container, if enabled
3. (optional) matrix-synapse vhost (matrix-synapse.conf), if matrix-corporal enabled
4. matrix-synapse container

We are setting `X-Forwarded-For` correctly in step #1, but were
overwriting it in step #2 with something inaccurate.

Not doing anything in step #2 is better than doing the wrong thing.
It's probably best if we append another reverse-proxy address there
though, although what we're doing now (with this patch) seems to yield
the correct result (when matrix-corporal is not enabled).

When matrix-corporal is enabled, we still seem to do the wrong thing for
some reason. It's something to be fixed later on.

During first setup postgres takes its time to get up and running, resulting in "postgres in startup" exceptions from synapse if you run without additional services that come in between. Hence suggesting increasing the time a bit to avoid having an error which heals itself and thus is hard to spot for newcomers.

This is something that got lost during
https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/456
and more specifically 4d62a75f6f.

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

Mostly affects people who disable the integrated `matrix-nginx-proxy`.

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/456
and more specifically 4d62a75f6f.

They're gone now: b8ce80e476

This ensures more timely updates of certifcates.

This seems to have been added to the list of "deprecated files to
remove" by mistake.

People who were disabling matrix-nginx-proxy (in favor of their own
nginx webserver) and also overriding `matrix_federation_public_port`,
found that the generated nginx configuration still hardcoded `8448`,
which forced their nginx server to use that, regardless of the fact
that `matrix_federation_public_port` was pointing elsewhere.

We now allow for the in-container federation port to be configurable,
and also automatically wire things properly.

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

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

This reverts commit fd3d48bb6d.

Normally this environment variable gets referred to from `settings.json.docker`,
but we have our own full configuration, which hardcodes `"trustProxy": true`,
thus making this useless.

This has been pointed out here:
fd3d48bb6d (commitcomment-47403097)

Same reasoning as in 1cd251ed78

This only seems to be affecting some people badly enough to cause
matrix-postgres not to start. Certain systemd versions probably handle
it better or something.

Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/889
(hopefully)