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)

This probably got lost somehow in all the work that happened in
https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/456

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

Adding more presets in the future would be nice.

We're talking about a webserver running on the same machine, which
imports the configuration files generated by the `matrix-nginx-proxy`
in the `/matrix/nginx-proxy/conf.d` directory.

Users who run an nginx webserver on some other machine will need to do
something different.

Related to: https://matrix.org/blog/2021/02/18/synapse-1-27-0-released#dropping-armv7-docker-images

The official Etherpad Docker image has no support for sqlite3 databases.

This give us the possibility to run multiple instances of
workers that that don't expose a port.

Right now, we don't support that, but in the future we could
run multiple `federation_sender` or `pusher` workers, without
them fighting over naming (previously, they'd all be named
something like `matrix-synapse-worker-pusher-0`, because
they'd all define `port` as `0`).