This gets us started on adding a Traefik role and hooking Traefik:

- directly to services which support Traefik - we only have a few of
  these right now, but the list will grow

- to matrix-nginx-proxy for most services that integrate with
  matrix-nginx-proxy right now

Traefik usage should be disabled by default for now and nothing should
change for people just yet.

Enabling these experiments requires additional configuration like this:

```yaml
devture_traefik_ssl_email_address: '.....'

matrix_playbook_traefik_role_enabled: true
matrix_playbook_traefik_labels_enabled: true

matrix_ssl_retrieval_method: none

matrix_nginx_proxy_https_enabled: false

matrix_nginx_proxy_container_http_host_bind_port: ''
matrix_nginx_proxy_container_federation_host_bind_port: ''

matrix_nginx_proxy_trust_forwarded_proto: true

matrix_nginx_proxy_x_forwarded_for: '$proxy_add_x_forwarded_for'

matrix_coturn_enabled: false
```

What currently works is:
reverse-proxying for all nginx-proxy based services **except** for the Matrix homeserver
(both Client-Server an Federation traffic for the homeserver don't work yet)

We expect `--tags=start` to handle systemd reloading, so we don't need
to do it manually each time we install/uninstall a .service file.

- forego removing Docker images - it's not effective anyway, because it
  only removes the last version.. which is a drop in the bucket, usually

- do not reload systemd - it's none of our business. `--tags=start`,
  etc., handle this

- combine all uninstall tasks under a single block, which only runs if
  we detect traces (a leftover systemd .service file) of the component.
  If no such .service is detected, we skip them all. This may lead to
  incorect cleanup in rare cases, but is good enough for the most part.

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

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.

Signed-off-by: Sebastian Gumprich <github@gumpri.ch>

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/1939

This commit adds a 'matrix-ntfy' role that runs Ntfy server in Docker with
simple configuration, and plumbing to add the role to the playbook.

TODO: documentation, self-check, database persistence.

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.

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

We do this by creating one more layer of indirection.

First we reach some generic vhost handling matrix.DOMAIN.
A bunch of override rules are added there (capturing traffic to send to
ma1sd, etc). nginx-status and similar generic things also live there.

We then proxy to the homeserver on some other vhost (only Synapse being
available right now, but repointing this to Dendrite or other will be
possible in the future).
Then that homeserver-specific vhost does its thing to proxy to the
homeserver. It may or may not use workers, etc.

Without matrix-corporal, the flow is now:
1. matrix.DOMAIN (matrix-nginx-proxy/matrix-domain.conf)
2. matrix-nginx-proxy/matrix-synapse.conf
3. matrix-synapse

With matrix-corporal enabled, it becomes:
1. matrix.DOMAIN (matrix-nginx-proxy/matrix-domain.conf)
2. matrix-corporal
3. matrix-nginx-proxy/matrix-synapse.conf
4. matrix-synapse

(matrix-corporal gets injected at step 2).

Fixes #586 (Github Issue)

No migration steps should be required.

We do use some `:latest` images by default for the following services:
- matrix-dimension
- Goofys (in the matrix-synapse role)
- matrix-bridge-appservice-irc
- matrix-bridge-appservice-discord
- matrix-bridge-mautrix-facebook
- matrix-bridge-mautrix-whatsapp

It's terribly unfortunate that those software projects don't release
anything other than `:latest`, but that's how it is for now.

Updating that software requires that users manually do `docker pull`
on the server. The playbook didn't force-repull images that it already
had.

With this patch, it starts doing so. Any image tagged `:latest` will be
force re-pulled by the playbook every time it's executed.

It should be noted that even though we ask the `docker_image` module to
force-pull, it only reports "changed" when it actually pulls something
new. This is nice, because it lets people know exactly when something
gets updated, as opposed to giving the indication that it's always
updating the images (even though it isn't).

In most cases, there's not really a need to touch the system
firewall, as Docker manages iptables by itself
(see https://docs.docker.com/network/iptables/).

All ports exposed by Docker containers are automatically whitelisted
in iptables and wired to the correct container.

This made installing firewalld and whitelisting ports pointless,
as far as this playbook's services are concerned.

People that wish to install firewalld (for other reasons), can do so
manually from now on.

This is inspired by and fixes #97 (Github Issue).