* Add matrix_bridges_msc4190_enabled flag for using msc4190 on supported mautrix bridges.

* Apply to_json to msc4190 in mautrix configs

* Add | to_json to mautrix bridge registration io.element.msc4190.

* require matrix_synapse_experimental_features_msc3202_device_masquerading_enabled for matrix_bridges_msc4190_enabled

* Also add msc4190 support for mautrix-telegram

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 do not let bridges update config files, so generation cannot happen.
We don't want the bridge to manage the config file anyway.

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

From `@<username>`, `@your_username`, `@example`, etc.

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

This moves the comments from being just in Jinja,
to actually ending up in the generated `labels` file,
which makes inspection of the final result easier.

Also, some new lines were added here and there to make labels
more legible.

The generated file may still include weird new-lines due to
various `if` statements yielding content or not, but that's not so ugly
anymore - now that we have proper start/end sections that are visible in
the final `labels` file.

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.

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.