After some checking, it seems like there's `/_synapse/client/oidc`,
but no such thing as `/_synapse/oidc`.

I'm not sure why we've been reverse-proxying these paths for so long
(even in as far back as the `matrix-nginx-proxy` days), but it's time we
put a stop to it.

The OIDC docs have been simplified. There's no need to ask people to
expose the useless `/_synapse/oidc` endpoint. OIDC requires
`/_synapse/client/oidc` and `/_synapse/client` is exposed by default
already.

This also adds labels for Synapse. Support for other homeservers and
components will be added later.

matrix-synapse/tasks/setup_uninstall.yml would previously not run unless
Synapse was completely disabled.

`spam_checker` has been deprecated for quite a while.
While it still probably works and while newer versions of
mjolnir-antispam still use it, we should switch to the new API.

Co-authored-by: Slavi Pantaleev <slavi@devture.com>

This was mostly affecting the stream writer (events) worker, which was
being reported as unhealthy. It wasn't causing any issues, but it just
looked odd and was confusing people.

As an alternative to hitting the regular `/health` healthcheck route (on
the "client" API which this stream writer does not expose),
we may have went for hitting some "replication" API endpoint instead.

This is more complicated and likely unnecessary.

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

Removed in 04b9483f0d (2022-11-28) when switching from matrix-postgres to
the devture-postgres external Ansible role.
More details: https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/master/CHANGELOG.md#matrix-postgres-has-been-replaced-by-the-comdevtureansiblerolepostgres-external-role

The `import_synapse_sqlite_db.yml` file and documentation has been adapted somewhat compared to before, so that:

- it doesn't try to start Postgres automatically. You need to handle
  this part manually
- it doesn't rely on the integrated Postgres and may potentially work
  with external Postgres instances just the same
- it doesn't wipe out the whole database anymore. By default, we assume
  it's empty anyway and there's no need for such things. If it's not,
  then it's also probably dangerous to be so destructive.

This is all completely untested, but will hopefully work.

It's the same as `matrix_docker_network` for now, so this practically
doesn't change anything.

Fixup related to https://github.com/matrix-org/synapse/pull/15431

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

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

It's unnecessary when `pusher_instances` is populated.

Source: 6acb6d772a

It's unnecessary when `federation_sender_instances` is populated.

Source: 6acb6d772a

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)