* Changes to allow a user to set the max participants on a jitsi
conference

* changed var name from jitsi_max_participants to matrix_prosody_jitsi_max_participants

* add prometheus-nginxlog-exporter role

* Rename matrix_prometheus_nginxlog_exporter_container_url to matrix_prometheus_nginxlog_exporter_container_hostname

* avoid referencing variables from other roles, handover info using group_vars/matrix_servers

* fix: stop service when uninstalling

fix: typo

move available arch's into a var

fix: text

* fix: prometheus enabled condition

Co-authored-by: ikkemaniac <ikkemaniac@localhost>

Related to

- c15e9a0edb
- 01a0527892

Related to 8f10c8b054

It's unnecessary when `pusher_instances` is populated.

Source: 6acb6d772a

It's unnecessary when `federation_sender_instances` is populated.

Source: 6acb6d772a

Synapse Worker configuration updates are coming later.

Related to 8005557061

Running with a user (like `matrix:matrix`) fails if Etherpad is enabled,
because `/matrix/etherpad` is owned by `matrix_etherpad_user_uid`/`matrix_etherpad_user_gid` (`5001:5001`).

The `matrix` user can't acccess the Etherpad directory for this reason
and Borgmatic fails when trying to make a backup.

There may be other things under `/matrix` which similarly use
non-`matrix:matrix` permissions.

Another workaround might have been to add `/matrix/etherpad` (and
potentially other things) to `matrix_backup_borg_location_exclude_patterns`, but:

- that means Etherpad won't be backed up - not great
- only excluding Etherpad may not be enough. There may be other files we
  need to exclude as well

---

Running with `root` is still not enough though.

We need at least the `CAP_DAC_OVERRIDE` capability, or we won't be able to read the
`/etc/borgmatic.d/config.yaml` configuration file (owned by
`matrix:matrix` with `0640` permissions).

---

Additionally, it seems like the backup process tries to write to at least a few directories:
- `/root/.borgmatic`
- `/root/.ssh`
- `/root/.config`

> [Errno 30] Read-only file system: '/root/.borgmatic'
> Error while creating a backup.
> /etc/borgmatic.d/config.yaml: Error running configuration file

We either need to stop mounting the container filesystem as readonly
(remove `--read-only`) or to allow writing via a `tmpfs`.

I've gone the `tmpfs` route which seems to work.

In any case, the mounted source directories (`matrix_backup_borg_location_source_directories`)
are read-only regardless, so our actual source files are protected from unintentional changes.

Without this, it's a string and borg says:

> At 'hooks.postgresql_databases[INDEX_HERE].port': '5432' is not of type 'integer'
> /etc/borgmatic/config.yaml /etc/borgmatic.d /tmp/.config/borgmatic/config.yaml /tmp/.config/borgmatic.d: No valid configuration files found

.. and fails to do anything.

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

Fixed in d134cd7c4c
(thanks to `alpine:latest` now being `alpine:3.17.0`, which includes
Postgres v15)

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

This path is accessed by the s3 storage provider stuff and needs to be
ensured.

Broken by 7c5c3aedc

Fixup for 7e2e2626a0

Some references were left unrenamed which caused `validate_config.yml`
to trigger.

This role is usable on its own and it's not tied to Matrix, so
extracting it out into an independent role that we install via
ansible-galaxy makes sense.

This also fixes the confusion from the other day, where
`matrix_postgres_*` had to be renamed to `devture_postgres_*`
(unless it was about `matrix_postgres_backup_*`).
We now can safely say that ALL `matrix_postgres_*` variables need to be
renamed.

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

Supersedes https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/2256

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

Regression since https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/2290

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.

This is done via devture_systemd_service_manager_services_list_auto
already.

We expect `--tags=start` to handle systemd reloading, so we don't need
to do it manually each time we install/uninstall a .service file.