* root path for the base domain

* Fix path when running in a container

Co-authored-by: Slavi Pantaleev <slavi@devture.com>

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

According to
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy,
having both a header and the `<meta>`-tag provided by Element itself is
not a problem. The 2 CSP policies get combined.

https://github.com/vector-im/element-web#configuration-best-practices

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

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

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/1061
and https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/1057

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

Not sure if this is beneficial though.

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

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

We may try to capture such calls and return a friendlier response (HTML
or JSON) saying "The Synapse Admin API is not enabled", but that may not
be desirable.

For now, we stick to what "upstream" recommends: "simply
don't proxy these APIs", which should lead to the same kind of 404 that
we have now.
See here: 6660912226/docs/reverse_proxy.md (synapse-administration-endpoints)

Jitsi-meet enabled websockets by default, claiming better reliability.
Matrix-nginx-proxy configuration has been set up according to the
Prosody documentation: https://prosody.im/doc/websocket

Potentially fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/1022

**HSTS Preloading:**
In its strongest and recommended form, the [HSTS policy](https://www.chromium.org/hsts) includes all subdomains, and indicates a willingness to be “preloaded” into browsers:
`Strict-Transport-Security: max-age=31536000; includeSubDomains; preload`

**X-Xss-Protection:**
`1; mode=block` which tells the browser to block the response if it detects an attack rather than sanitising the script.

More Production ready nginx headers for Matrix client element.

- duplicate X-Content-Type-Options
- X-Frame-Options header
- Referrer-Policy [Might consider adding variable]
- Secure flag with cookies
- matrix_grafana_content_security_policy variable for [Content Security Policy](https://grafana.com/docs/grafana/latest/administration/configuration/#content_security_policy)

X-XSS-Protection: 1; mode=block; header, for basic XSS protection in legacy browsers.
X-Content-Type-Options: nosniff header, to disable MIME sniffing

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

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.

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.

This ensures more timely updates of certifcates.

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.

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.

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