The newly extracted role also has native Traefik support,
so we no longer need to rely on `matrix-nginx-proxy` for
reverse-proxying to Ntfy.

The new role uses port `80` inside the container (not `8080`, like
before), because that's the default assumption of the officially
published container image. Using a custom port (like `8080`), means the
default healthcheck command (which hardcodes port `80`) doesn't work.
Instead of fiddling to override the healthcheck command, we've decided
to stick to the default port instead. This only affects the
inside-the-container port, not any external ports.

The new role also supports adding the network ranges of the container's
multiple additional networks as "exempt hosts". Previously, only one
network's address range was added to "exempt hosts".

Related to 6a52be7987 and 28e7ef9c71f02

Previously, it had to go through matrix-nginx-proxy.
It's exposed to Traefik directly via container labels now

This gets us started on adding a Traefik role and hooking Traefik:

- directly to services which support Traefik - we only have a few of
  these right now, but the list will grow

- to matrix-nginx-proxy for most services that integrate with
  matrix-nginx-proxy right now

Traefik usage should be disabled by default for now and nothing should
change for people just yet.

Enabling these experiments requires additional configuration like this:

```yaml
devture_traefik_ssl_email_address: '.....'

matrix_playbook_traefik_role_enabled: true
matrix_playbook_traefik_labels_enabled: true

matrix_ssl_retrieval_method: none

matrix_nginx_proxy_https_enabled: false

matrix_nginx_proxy_container_http_host_bind_port: ''
matrix_nginx_proxy_container_federation_host_bind_port: ''

matrix_nginx_proxy_trust_forwarded_proto: true

matrix_nginx_proxy_x_forwarded_for: '$proxy_add_x_forwarded_for'

matrix_coturn_enabled: false
```

What currently works is:
reverse-proxying for all nginx-proxy based services **except** for the Matrix homeserver
(both Client-Server an Federation traffic for the homeserver don't work yet)

This extends the collection with support for seamless authentication at the Jitsi server using Matrix OpenID.

1. New role for installing the [Matrix User Verification Service](https://github.com/matrix-org/matrix-user-verification-service)
2. Changes to Jitsi role: Installing Jitsi Prosody Mods and configuring Jitsi Auth
3. Changes to Jitsi and nginx-proxy roles: Serving .well-known/element/jitsi from jitsi.DOMAIN
4. We updated the Jitsi documentation on authentication and added documentation for the user verification service.

More details about the new key type can be found here:
https://eff-certbot.readthedocs.io/en/stable/using.html#rsa-and-ecdsa-keys

Existing RSA-based keys will continue to renew as RSA until manual
action is taken. Example from the documentation above:
> certbot renew --key-type ecdsa --cert-name example.com --force-renewal

In the future, we may add a command which does this automatically for
all domains.

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

* Add task to configure a standalone JVB on a different server

* add missing file

* set nginx config

* update prosody file and expose port 5222

* change variable name to server id

* formatting change

* use server id of jvb-1 for the main server

* adding documentation

* adding more jvbs

* rename variable

* revert file

* fix yaml error

* minor doc fixes

* renaming tags and introducing a common tag

* remove duplicates

* add mapping for jvb to hostname/ip

* missed a jvb_server

* Update roles/matrix-nginx-proxy/templates/nginx/conf.d/matrix-jitsi.conf.j2

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

* PR review comments and additional documentation

* iterate on dict items

* Update docs/configuring-playbook-jitsi.md

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

* Update docs/configuring-playbook-jitsi.md

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

* Update docs/configuring-playbook-jitsi.md

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

* Update docs/configuring-playbook-jitsi.md

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

* Update docs/configuring-playbook-jitsi.md

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

* Update docs/configuring-playbook-jitsi.md

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

* Update docs/configuring-playbook-jitsi.md

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

* adding documentation around the xmpp setting

* add common after

* reduce the number of services during init of the additional jvb

* remove rogue i

* revert change to jitsi init as it's needed

* only run the jvb service on the additional jvb host

* updating docs

* reset default and add documentation about the websocket port

* fix issue rather merge with master

* add missing role introduced in master

* this role is required too

* Adding new jitsi jvb playbook, moving setup.yml to matrix.yml and creating soft link

* updating documentation

* revert accidental change to file

* add symlink back to roles to aid running of the jitsi playbook

* Remove extra space

* Delete useless playbooks/roles symlink

* Remove blank lines

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

This paves the way for installing other roles into `roles/galaxy` using `ansible-galaxy`,
similar to how it's done in:

- https://github.com/spantaleev/gitea-docker-ansible-deploy
- https://github.com/spantaleev/nextcloud-docker-ansible-deploy

In the near future, we'll be removing a lot of the shared role code from here
and using upstream roles for it. Some of the core `matrix-*` roles have
already been extracted out into other reusable roles:

- https://github.com/devture/com.devture.ansible.role.postgres
- https://github.com/devture/com.devture.ansible.role.systemd_docker_base
- https://github.com/devture/com.devture.ansible.role.timesync
- https://github.com/devture/com.devture.ansible.role.vars_preserver
- https://github.com/devture/com.devture.ansible.role.playbook_runtime_messages
- https://github.com/devture/com.devture.ansible.role.playbook_help

We just need to migrate to those.

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.

`localhost` may resolve to `::1` on some IPv6-enabled systems, which will
not work, because we only potentially expose container ports on
`127.0.0.1` when nginx is disabled (`matrix_nginx_proxy_enabled: false`),
not on `::1`.

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

We redefine these variables in `group_vars/matrix_servers`, but it's better
to have some defaults in the role as well.

.. regardless of whether matrix-nginx-proxy runs in a container or not

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

* Add support for obtain ECDSA keys

* Replace matrix_ssl_lets_encrypt_use_ecdsa_keys for matrix_ssl_lets_encrypt_key_type

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.