See these last commits:

tulir/mautrix-signal@4fc34330c1f6947aece67863b0d04da34c776f80

tulir/mautrix-signal@64bc5c36a509ba435a0b01cf44afb1b5d2642efd

tulir/mautrix-signal@ddda1666d41d28750cc59d070e4388b24add6ad9

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

This also simplifies Prerequisites, which is great.

It'd be nice if we were doing these checks in some optional manner
and reporting them as helpful messages (using
`matrix_playbook_runtime_results`), but that's more complicated.
I'd rather drop these checks completely.

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.

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.