As stream writer workers are also powered by the `generic_worker`
Synapse app, this necessitated that we provide means for distinguishing
between them and regular `generic_workers`.

I've also taken the time to optimize nginx configuration generation
(more Jinja2 macro usage, less duplication).

Worker names have also changed.
Workers are now named sequentially like this:
- `matrix-synapse-worker-0-generic`
- `matrix-synapse-worker-1-stream-writer-typing`
- `matrix-synapse-worker-2-pusher`

instead of `matrix-synapse-worker_generic_worker-18111` (indexed with a
port number).

People who modify `matrix_synapse_workers_enabled_list` directly will
need to adjust their configuration.

`frontend_proxy` workers have been superseded by `generic_worker` workers.
Related to https://github.com/matrix-org/synapse/pull/13645

This commit adds a 'matrix-ntfy' role that runs Ntfy server in Docker with
simple configuration, and plumbing to add the role to the playbook.

TODO: documentation, self-check, database persistence.

When setting `matrix_nginx_proxy_enabled: false` and enabling authentication on the metrics endpoint, the htpasswd file is hardcoded to the nginx-proxy container dir, this changes the hardcoded value to a variable so the path can be updated

People often report and ask about these "failures".
More-so previously, when the `docker kill/rm` output was collected,
but it still happens now when people do `systemctl status
matrix-something` and notice that it says "FAILURE".

Suppressing to avoid further time being wasted on saying "this is
expected".

For an unknown reason prometheus ignored the given "numeric" index and replaced it by 1. This made it not work properly, plus multiple workers of same types were not differentiable. With a "string" index, it works as intended.

* Add support for obtain ECDSA keys

* Replace matrix_ssl_lets_encrypt_use_ecdsa_keys for matrix_ssl_lets_encrypt_key_type

Reverts b1b4ba501fdfaa, 90c9801c560b6, a3c84f78ca9c65a, ..

I haven't really traced it (yet), but on some servers, I'm observing
`ansible-playbook ... --tags=start` completing very slowly, waiting
to stop services. I can't reproduce this on all Matrix servers I manage.
I suspect that either the systemd version is to blame or that some
specific service is not responding well to some `docker kill/rm` command.

`ExecStop` seems to work great in all cases and it's what we've been
using for a very long time, so I'm reverting to that.

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

Seems like Dendrite encourages serving both the Client and Federation
API at the same port.

Coming from Synapse and how things are done there, we have separate
ports. Using separate ports probably makes matrix-corporal (etc.)
integration easier, so separating the APIs by default probably makes
sense.

ExecStopPost should allow us to clean up (docker kill + docker rm)
even if the ExecStart (docker run ..) command failed, and not just after
a graceful service stop was initiated.

Source: https://www.freedesktop.org/software/systemd/man/systemd.service.html#ExecStopPost=

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

1f196f59cb

https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/1311#issuecomment-945718866

when matrix_nginx_proxy_proxy_synapse_metrics is enabled

From 6f80292745

* add timeout param for nginx proxy

default value matrix_nginx_proxy_request_timeout is 60s

* default matrix_nginx_proxy_request_timeout - 60s

* few more variables for request timeout

* Update nginx.conf.j2

* Update nginx.conf.j2

* 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.