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

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

Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/969

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