Issues and Pull Requests were not migrated to the new
organization/repository, so `matrix-org/synapse/pull` and
`matrix-org/synapse/issues` references were kept as-is.

`matrix-org/synapse-s3-storage-provider` references were also kept,
as that module still continues living under the `matrix-org` organization.

This patch mainly aims to change documentation-related things, not actual
usage in full yet. For polish that, another more comprehensive patch is coming later.

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.

We'd be adding integration with an internal Traefik entrypoint
(`matrix_playbook_internal_matrix_client_api_traefik_entrypoint`),
so renaming helps disambiguate things.

There's no need for deperecation tasks, because the old names
have only been part of this `bye-bye-nginx-proxy` branch and not used by
anyone publicly.

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.

Related to e5130372b9.

Depending on the `options` that people provide, this may break
compatibility.

This is backward-compatible with what we had before. We're not changing
the SSL mode - just making it configurable.

Most components are defaulting to `sslmode=disable`, while some
(`matrix-bot-matrix-reminder-bot` and others) do not specify an `sslmode` at all.

We're making sslmode configurable, because certain external Postgres
servers may be configured to require SSL encryption.
In such cases `sslmode=disable` does not work and needs to be changed to
`sslmode=require` or something else (`verify-ca`, `verify-full`, etc).

Untested.

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

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

to a conditional block, similar to synapse. Also adds the
DOCKER_BUILDKIT=1 explicitly to ensure buildkit is used.

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

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

Regression since https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/2290

* added dendrite captcha options

* added hcaptcha doc

* proper url

* Apply suggestions from code review

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

* Update main.yml

* renamed captcha vars to new naming scheme

* change vars to new format

* Rename back some incorrect renamed variables

These variables are either not just part of the `client_api` subsection,
or are not even part of that section at all. They shouldn't have been
renamed in baaef2ed616e2645550d9

* Fix up naming inconsistencies

Some of these variables had been renamed in one place,
but not in other places, so it couldn't have worked that way.

* Add validation/deprecation for renamed Dendrite variables

Related to 4097898f885cf4c73, baaef2ed616e2645550, 68f4418092fa8ad
and a0b4a0ae6b2f1f18

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

- 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.