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.

https://gitlab.com/signald/signald/-/blob/main/releases/0.19.0.md
https://gitlab.com/signald/signald/-/blob/main/releases/0.19.1.md
https://gitlab.com/signald/signald/-/blob/main/releases/0.20.0.md

Fixup for https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/1899

According to https://signald.org/articles/install/docker/#migrating-from-versions-before-0180,
This release only chowns files if the container is running as root. See also this upstream commit:
3bb7e8d2c1

The maunium fork of Signald is no longer up-to-date (does not publish
0.18.0.. at least not yet) and all the necessary changes are now upstream.

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

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

Related to https://signald.org/articles/install/docker/#migrating-from-versions-before-0180

> Prior to 0.18.0 the signald container image used the root user, which is not recommended for security reasons. This was fixed in the 0.18.0 release which will start as root, fix permissions on the volume, then drop to the non-root user and start signald. Future images will start as the non-root user, so if you’re upgrading make sure to run 0.18.0 at least once.
> A special tag, 0.18.0-non-root, will be published. it starts as the non-root user and does not fix permissions on the volume.

Improved setup through template file

Co-authored-by: Jan <31133207+Jaffex@users.noreply.github.com>

Per default relay bot functionality is disabled; the bridge user permissions depends on the relay bot, if enabled the base domain users are on level relay, else remain on user;

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

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

While it's kind of nice having it, it's also somewhat raw
and unnecessary.

Having a good default and not even mentioning it seems better
for most users.

People who need a more exposed bridge (rare) can use
override the default configuration using
`matrix_mautrix_signal_configuration_extension_yaml`.

The answer to these is: it's good to have them in both places.
The role defines the obvious things it depends on (not knowing
what setup it will find itself into), and then
`group_vars/matrix_servers` "extends" it based on everything else it
knows (the homeserver being Synapse, whether or not the internal
Postgres server is being used, etc.)