* Allow the mautrix whatsapp relaybot to be enable with a variable

This allows a user to enable the relaybot by setting a variable in
`vars.yml` in the same way that the mautrix signal relaybot is
configured.

* Correct default values for mautrix whatsapp relaybot variables

* Add documentation for using the relaybot with mautrix whatsapp

* Adjust variable names to better reflect what they do

* Set default variables properly and use to_json in template

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

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

Fixes the following issue when trying to use the !pm <phone number> command: https://gitlab.com/signald/signald/-/issues/345

Conduit update 0.5.0 fixed the issue, so this is no longer needed.

Related to:

- https://github.com/matrix-org/synapse/pull/14551/files
- https://github.com/matrix-org/synapse/pull/14619/files

Signed-off-by: Joe Kappus <joe@wt.gd>

Please note that This Mjolnir version bump technnically is missing some extra stuff that mjolnir claims we should do but it didnt work when i tried it and well my mjolnir deployment has been running this since release day almost and its fine. No errors in log that are unexpected. (Mjolnir throws errors in the log for anyone who wonders for various things that are fine. Like if a protection is off that is an error. Its due to how matrix-bot-lib works.)

Untested

improve nginxlog matches to group URI's

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

Without these:

- `--tags=install-synapse` and `--tags=install-all` would be incomplete
and will not contain Synapse worker configuration

- `--tags=install-synapse-reverse-proxy-companion` and
  `--tags=setup-synapse-reverse-proxy-companion` would not contain
  Synapse worker configuration

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