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

Related to:
- https://github.com/matrix-org/synapse/pull/9407
- https://github.com/matrix-org/synapse/pull/7855

don't bind to any host port if nginx_proxy is used
only bind to localhost if it's not used

This leads to much easier management and potential safety
features (validation). In the future, we could try to avoid port
conflicts as well, but it didn't seem worth the effort to do it now.
Our port ranges seem large enough.

This can also pave the way for a "presets" feature
(similar to `matrix_nginx_proxy_ssl_presets`) which makes it even easier
for people to configure worker counts.

`::` leads to errors like:

> socket.gaierror: [Errno -9] Address family for hostname not supported

These validation tasks should only run when Prometheus is enabled.

It seems like it doesn't cause any issues for any of these services.

The quotes around "host" for both `--pid` and `--net` were
causing trouble for me:

> docker: --pid: invalid PID mode.

and:

> docker: Error response from daemon: network "host" not found.

I've also changed the `-v` call to `--mount` for consistency with the
rest of the playbook.

Changed `matrix_mautrix_signal_docker_image_force_pull` to `matrix_mautrix_signal_daemon_docker_image_force_pull` when force pulling the daemon

Using the hardcoded IP did break while I was
messing with IPv6 stuff on the other branch

By running it in a more privileged container with access to the host network stack and such