Signed-off-by: gardar <gardar@users.noreply.github.com>

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

Ref: https://github.com/mautrix/signal/releases/tag/v0.5.0

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

Related to https://github.com/mautrix/signal/issues/422

* chore(deps): update signal bridge version + config

* style(deps): rename default note to self config variable

* Add to_json for additional safety

---------

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

.. because matrix_mautrix_signal_version is used in other places
which do not expect it. For example: `matrix_mautrix_signal_container_image_self_build_branch`

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

0.23.1 no longer syncs groups properly, the solution is to use 0.23.2, which works as expected

* one var to control encryption across all bridges

* move var to matrix-base

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

`metrics_enabled` should only expose the metrics locally, on the
container network, so that a local Prometheus can consume them.

Exposing them publicly should be done via a separate toggle (`metrics_proxying_enabled`).
This is how all other roles work, so this makes these mautrix roles consistent with the rest.

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

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.

ref: https://github.com/mautrix/signal/releases/tag/v0.4.1

ref: https://gitlab.com/signald/signald/-/issues/343

There is no docker tag in UI, but it exists:

```
docker pull registry.gitlab.com/signald/signald:0.21.0
0.21.0: Pulling from signald/signald
2f42a0d7a7b7: Pull complete 
81c2fb1b6074: Pull complete 
7e8b9a51d6b6: Pull complete 
f6ed8fd77301: Pull complete 
64e6fa036bdc: Pull complete 
5e98b5369603: Pull complete 
f2a9b80dd9fc: Pull complete 
Digest: sha256:201cf93efba689aa0319d2a480deea8ffb7dcdfbda31ea45932fccf4c7626ab9
Status: Downloaded newer image for registry.gitlab.com/signald/signald:0.21.0
registry.gitlab.com/signald/signald:0.21.0
```

* Auto trust new signal identities

from signald doku: when a remote key changes, set trust level to TRUSTED_UNVERIFIED instead of UNTRUSTED 
I find it much more convenient when new identities are automatically recognized as trusted, as the process to do that manually is cumbersome.
Should this the default behavior, or should i add an option to configure this behavior?

* Added option to trust new signal identities

* Using env file

* Renamed variable

* Corrected typo

* Use fully-qualified Ansible module name

* removed option trust_new_keys

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

Not doing {% if matrix_admin %} checks in the YAML also fixes some issues
with indentation being incorrect sometimes.

This should be backward compatible, except for mautrix-signal's case
where `matrix_mautrix_signal_bridge_permissions` previously existed
as a string, not a dictionary. `tasks/validate_config.yml` will catch
the problem an even provide a quick fix.

Reference: https://ansible-lint.readthedocs.io/en/latest/default_rules/#git-latest

Our variable naming is not necessarily consistent across roles.
I've tried to follow the naming conventions of each individual role.
All new variables are suffixed with `_version`, but the prefix may be
somewhat different.