ExecStopPost should allow us to clean up (docker kill + docker rm)
even if the ExecStart (docker run ..) command failed, and not just after
a graceful service stop was initiated.

Source: https://www.freedesktop.org/software/systemd/man/systemd.service.html#ExecStopPost=

Until now, we were leaving services "enabled"
(symlinks in /etc/systemd/system/multi-user.target.wants/).

We clean these up now. Broken symlinks may still exist in older
installations that enabled/disabled services. We're not taking care
to fix these up. It's just a cosmetic defect anyway.

As per earlier comment (see from tulir) the sequence has been changed.

Updated settings in template file:
* relay for any user
* user permissions only for HS domain users

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

Improved setup through template file

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

Permissions, when set in the template, will be augmented rahter than replaced when using matrix_mautrix_signal_configuration_extension_yaml. Therefore, permissions shall only be set in the defaults/vars.yml or in the HS specific vars.yml file

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;

Enable / disable relay bot functionality as configuratoin paramter; set bridge permissions for base domain users to user level

We'd rather not suppress pull errors or run self-build tasks if pulling fails.

See these last commits:

tulir/mautrix-signal@4fc34330c1f6947aece67863b0d04da34c776f80

tulir/mautrix-signal@64bc5c36a509ba435a0b01cf44afb1b5d2642efd

tulir/mautrix-signal@ddda1666d41d28750cc59d070e4388b24add6ad9

This adds https://github.com/matrix-org/matrix-doc/pull/2409 to the
appservice registrations, enabling synapse to push EDUs to appservices.

Changed `matrix_mautrix_signal_docker_image_force_pull` to `matrix_mautrix_signal_daemon_docker_image_force_pull` when force pulling the daemon

If they do, our next playbook runs would simply revert it
and report "changed" for that task.

There's no benefit to letting the bridge spew a new config file.

This does not apply to the mautrix whatsapp bridge, because that one
is written in Go (not Python) and takes different flags. There's no
equivalent flag there.

Fixes a regression introduced in f6097fbba1fb, which was cauing Synapse
to die with this error message:

> ValueError: sender_localpart needs characters which are not URL encoded.

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

These are just defensive cleanup tasks that we run.
In the good case, there's nothing to kill or remove, so they trigger an
error like this:

> Error response from daemon: Cannot kill container: something: No such container: something

and:

> Error: No such container: something

People often ask us if this is a problem, so instead of always having to
answer with "no, this is to be expected", we'd rather eliminate it now
and make logs cleaner.

In the event that:
- a container is really stuck and needs cleanup using kill/rm
- and cleanup fails, and we fail to report it because of error
suppression (`2>/dev/null`)

.. we'd still get an error when launching ("container name already in use .."),
so it shouldn't be too hard to investigate.

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

> WARNING: Error loading config file: .dockercfg: $HOME is not defined

.. which appeared in Docker 20.10.

We'll be adding `.timer` units later on, so it's good to be
more explicit.

We try to only use console logging (going to journald) for everything,
instead of logging things twice (or more).

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