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

That is:
- enabled in the role by default
- disabled in the compilation (playbook), if considered an optional
component

This variable was previously undefined in the role and was only getting
defined via `group_vars/matrix_servers`.

We now properly initialize it (and its good default value) in the role
itself.

Fixes a regression introduced in ffe649a240

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

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

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

Fixes a regression caused by a5ee39266c.

If the user id and group id were different than 991:991
(which used to be a hardcoded default for us long ago),
there was a mismatch between what Synapse was trying to use (991:991)
and what it was actually started with (in `--user=..`). It was then
trying to change ownership, which was failing.

This was mostly affecting newer installations which were not using the
991:991 defaults we had long ago (since a1c5a197a9).

This allows us to benefit from helpful things it does for us,
like enabling jemalloc: https://github.com/matrix-org/synapse/pull/8553

We weren't going through `start.py` before, because it was causing some
conflict with our `docker run --user=...` stuff, but it doesn't seem
to be a problem anymore.

Having done this, we won't need to do things like
https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/941
anymore.

- 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.