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

Related to:

- https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3470
- https://github.com/hifi/heisenbridge/releases/tag/v1.15.0

During testing, it appears that Heisenbridge generated media URLs
that look like this: `{media_url}/_matrix/media/v3/download/DOMAIN/FILE_ID/FILE_NAME`.

This seems off. We were expecting `{media_url}/_heisenbridge/media/something`
(e.g. `https://matrix.DOMAIN/heisenbridge/_heisenbridge/media/something`, leading to its own media proxy),
but Heisenbridge still seems to be generating URLs destined for the homeserver's Media API.

Until we figure out why that is, `media_url` remains pointed to the homeserver URL (just like before),
so that the bot can continue operating like before.

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.

Reverts b1b4ba501fdfaa, 90c9801c560b6, a3c84f78ca9c65a, ..

I haven't really traced it (yet), but on some servers, I'm observing
`ansible-playbook ... --tags=start` completing very slowly, waiting
to stop services. I can't reproduce this on all Matrix servers I manage.
I suspect that either the systemd version is to blame or that some
specific service is not responding well to some `docker kill/rm` command.

`ExecStop` seems to work great in all cases and it's what we've been
using for a very long time, so I'm reverting to that.

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=

Fixes running the container as an unprivileged user.