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