Related to:

- 682d31c702
- ecbe0ddbe7
- f4fc83ac75

.. and https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/2569

Larger deployments may wish to run migration more often.

Related to https://docs.docker.com/engine/deprecated/#separator--of---security-opt-flag-on-docker-run

Related to https://github.com/matrix-org/synapse/commit/3479599387164aca2613e88d169719

Related to:

- https://github.com/matrix-org/synapse/pull/14551/files
- https://github.com/matrix-org/synapse/pull/14619/files

Signed-off-by: Joe Kappus <joe@wt.gd>

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

Without these:

- `--tags=install-synapse` and `--tags=install-all` would be incomplete
and will not contain Synapse worker configuration

- `--tags=install-synapse-reverse-proxy-companion` and
  `--tags=setup-synapse-reverse-proxy-companion` would not contain
  Synapse worker configuration

Related to

- c15e9a0edb
- 01a0527892

Related to 8f10c8b054

It's unnecessary when `pusher_instances` is populated.

Source: 6acb6d772a

It's unnecessary when `federation_sender_instances` is populated.

Source: 6acb6d772a

Synapse Worker configuration updates are coming later.

This path is accessed by the s3 storage provider stuff and needs to be
ensured.

Broken by 7c5c3aedc

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.

We had checks to avoid stopping/deleting systemd services for workers
that used to exist and will continue to exist, but we were deleting
config files for workers each time.. Only to recreate them again later.

This lead to:

- too many misleading "changed" tasks
- too much unnecessary work
- potential failures during playbook execution possibly leaving the
  system in a bad state (no worker config files)