* feat: support container_network=host across all roles + systemd templates

Mirror the pattern Slavi introduced for matrix-coturn (aafa8f0) across the
fork: every 'Ensure X container network is created' task gets a
'when: <var> not in ["", "host"]' guard so MDAD does not try to
docker_network create a network literally named 'host' (returns 403,
since host is a pre-defined Docker network).

Mirror the same guard in every systemd unit template that does
'ExecStartPre=docker network connect <addnet> <container>' loops over
matrix_<role>_container_additional_networks: skip the connects when the
container is on host networking (where additional --network attaches
are invalid).

Unblocks DiD setups where MDAD-managed containers share their host's
network namespace (matrix-mdad outer compose service joined to central
postgres/openldap networks) to reach external services on the outer
Docker daemon.

* Simplify container network guards (!= 'host') and fix duplicate when

Guarding on the empty string ('') as well was misleading: systemd unit
templates still render an unconditional --network= flag, so an empty
network value produces a broken docker create command. Only 'host' is
actually supported, so only guard on that. This also matches the
existing convention in the Traefik role
(when: traefik_container_network != 'host').

Also fix a duplicate when key in the meshtastic-relay role, where the
network-creation task already had a when condition - the two are now
combined into a list.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

---------

Co-authored-by: Slavi Pantaleev <slavi@devture.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

Roles affected: appservice-discord, appservice-irc, beeper-linkedin,
heisenbridge, hookshot, mautrix-bluesky, mautrix-discord,
mautrix-gmessages, mautrix-googlechat, mautrix-signal, mautrix-slack,
mautrix-twitter, mautrix-whatsapp, mautrix-wsproxy, mx-puppet-groupme,
mx-puppet-steam, postmoogle, sms, steam, cactus-comments, element,
fluffychat, schildichat, conduit, corporal, dendrite,
ldap-registration-proxy, media-repo, pantalaimon,
prometheus-nginxlog-exporter, registration, sygnal, synapse-admin,
user-verification-service.

For each role: renamed _docker_image* variables to _container_image*
(and _docker_src_files_path to _container_src_files_path where
applicable), added deprecation entries in validate_config.yml, and
updated group_vars/docs references.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/4445

Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>

`-t` works on both old and new Docker versions, so it's best to use that.

We used to pass the shared secret for double-puppeting via a
`login_shared_secret` parameter, which doesn't seem to exist anymore.
The proper way to do it is via `login_shared_secret_map`.

The comments for `login_shared_secret_map` seem to indicate that it's
only usable with the shared-secret-auth password provider.

However, this bridge is based on mautrix-python (`>=0.20.5,<0.21`) as
per its `requirements.txt`
Support for double-puppeting via arbitrary access tokens landed in
mautrix-python 0.20.1 (6f25b62e80/CHANGELOG.md (L44-L53),)
so it should be possible to use appservice double-puppet.
Related to af04ca1238

A bunch of other parameters seem to have moved around as well.

This patch introduces some new Ansible variables for controlling
additional settings related to encryption, etc.

This is an attempt at optimizing service startup.

The effect is most pronounced when many services are restarted one by one.
The systemd service manager role sometimes does this - for example when `just install-service synapse` runs.
In such cases, a 5-second delay for each Synapse worker service
(or other bridge/bot service that waits on the homeserver) quickly adds up to a lot.

When services are all stopped fully and then started, the effect is not so pronounced, because
`matrix-synapse.service` starts first and pulls all worker services (defined as `Wants=` for it).
Later on, when the systemd service manager role "starts" these worker services, they're started already.
Even if they had a 5-second wait each, it would have happened in parallel.

`--mount` is safer, as `-v` has the side-effect of creating the "source"
destination as a directory if it doesn't exist yet.
We don't need such magic.

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.