As mentioned in https://github.com/matrix-org/sliding-sync/issues/31#issuecomment-1640321110
images are available for arm64 already.

Making the group match the Ansible task tags allows people to do `just install-service matrix-media-repo` and have that trigger both `--tags=matrix-media-repo` and also restart just that single group (`matrix-media-repo`).

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

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

This contribution is provided by GRNET S.A. (grnet.gr).

This contribution is provided by GRNET S.A. (grnet.gr).

This contribution is provided by GRNET S.A. (grnet.gr).

This restores consistency with other services.

Related to 8f903fa621

Previously `just install-service buscarron` would not fully work,
because:

- the systemd services were indeed tagged with `buscarron`

- however, the actual installation tasks are not
  `install-buscarron`/`setup-buscarron`, but rather
  `install-bot-buscarron`/`setup-bot-buscarron`

Services are now tagged with the `bot-` prefix to match the tags.

Regression since 1d00d15482

If Traefik is used, these are not Wanted services.

This allows for doing `just install-service client-element` to get only
Element rebuilt and restarted.

This makes us rebuild/restart exporters when running `just install-service prometheus`,
which we don't like.

i was sleepy lol

It will, additionally, be connected to the devture-postgres network, if
devture-postgres is enabled.

This allows people to try out the new Element X clients, which need to
run against the sliding-sync proxy (https://github.com/matrix-org/sliding-sync).

Supersedes https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/2515

The code is based on the existing PR (#2515), but heavily reworked. Major changes:

- lots of internal refactoring and variable renaming

- fixed self-building to support non-amd64 architectures

- changed to talk to the homeserver locally, over the container network (not
  publicly)

- no more matrix-nginx-proxy support due to complexity (see below)

- no more `matrix_server_fqn_sliding_sync_proxy` in favor of
  `matrix_sliding_sync_hostname` and `matrix_sliding_sync_path_prefix`

- runs on `matrix.DOMAIN/sliding-sync` by default, so it can tried
  easily without having to create new DNS records

The variable was necessary when multiple playbooks could have
potentially tried to manage a shared `devture-traefik.serivce` systemd service
and shared `/devture-traefik` directory.

Since adcc6d9723086f65f1a72, we use our own `/matrix/traefik`
(`matrix-traefik.service`) installation and no conflicts can arise.
It's safe to always enable the role, just like we do with all the other roles.

The migration is automatic. Existing users should experience a bit of
downtime until the playbook runs to completion, but don't need to do
anything manually.

This change is provoked by https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/2535

While my statements there ("Traefik is a shared component among
sibling/related playbooks and should retain its global
non-matrix-prefixed name and path") do make sense, there's another point
of view as well.

With the addition of docker-socket-proxy support in bf2b54080789f7e,
we potentially introduced another non-`matrix-`-prefixed systemd service
and global path (`/devture-container-socket-proxy`). It would have
started to become messy.

Traefik always being called `devture-traefik.service` and using the `/devture-traefik` path
has the following downsides:

- different playbooks may write to the same place, unintentionally,
  before you disable the Traefik role in some of them.
  If each playbook manages its own installation, no such conflicts
  arise and you'll learn about the conflict when one of them starts its
  Traefik service and fails because the ports are already in use

- the data is scattered - backing up `/matrix` is no longer enough when
  some stuff lives in `/devture-traefik` or `/devture-container-socket-proxy` as well;
  similarly, deleting `/matrix` is no longer enough to clean up

For this reason, the Traefik instance managed by this playbook
will now be called `matrix-traefik` and live under `/matrix/traefik`.

This also makes it obvious to users running multiple playbooks, which
Traefik instance (powered by which playbook) is the active one.
Previously, you'd look at `devture-traefik.service` and wonder which
role was managing it.

With these changes, we:

- install https://github.com/Tecnativa/docker-socket-proxy via the
  https://github.com/devture/com.devture.ansible.role.container_socket_proxy Ansible role

- make Traefik access the Docker API via TCP by connecting to this
  socket proxy

- .. which allows us to run the Traefik container with less privileges
  (non-`root`, dropped capabilities)

Completely untested.

This new role also adds native Traefik support and support for other
(non-`amd64`) architectures via self-building.

If someone disables ACME, then they're using their own certificates
somehow. There's nothing to dump from an `acme.json` file.

We don't need these 2 roughly-the-same settings related to the
traefik-certs-dumper role.

For Traefik, it makes sense, because it's a component used by the
various related playbooks and they could step onto each other's toes
if the role is enabled, but Traefik is disabled (in that case, uninstall
tasks will run).

As for Traefik certs dumper, the other related playbooks don't have it,
so there's no conflict. Even if they used it, each one would use its own
instance (different `devture_traefik_certs_dumper_identifier`), so there
wouldn't be a conflict and uninstall tasks can run without any danger.

This allows people wishing to change or unset the resolver,
to have a single variable which they can toggle.

Unsetting the resolver is useful for using your own certificates
(not coming from a certificate resolver).