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

* fix: only add element related entries to client well-known if element is enabled

* Fix matrix-base/defaults/main.yml syntax

---------

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

* Enable location sharing in Element

* Update roles/custom/matrix-client-element/tasks/validate_config.yml

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

* Update roles/custom/matrix-client-element/tasks/setup_install.yml

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

* Rename location sharing vars to be consistent with other vars

* Rename style.json to map_style.json

* Add m.tile_server section to /.well-known/matrix/client

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

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.

According to the docs, "e2ee" is already under "io.element":
  https://github.com/vector-im/element-web/blob/develop/docs/e2ee.md#disabling-encryption-by-default
however "jitsi" is still under "im.vector.riot":
  https://github.com/vector-im/element-web/blob/develop/docs/jitsi.md#configuring-element-to-use-your-self-hosted-jitsi-server

For now let's just maintain backward and forward compatibility for both
settings since the client version is out of the control of this
playbook.

Related to https://github.com/vector-im/riot-web/pull/13914

This will not work yet, as no version of Riot currently supports it.
It's expected to land in riot-web v1.5.16 via matrix-org/matrix-react-sdk#4348.

https://github.com/matrix-org/matrix-doc/pull/1957

Yay Riot iOS now supports integration manager discovery!

Riot used to be fine with it being blank but now it complains. This creates an ugly looking comma when there is an identity server configured but I guess that's fine.

Use Jinja2 lstrip_blocks option in templates to ensure consistent
indentation in generated files.

As suggested in #63 (Github issue), splitting the
playbook's logic into multiple roles will be beneficial for
maintainability.

This patch realizes this split. Still, some components
affect others, so the roles are not really independent of one
another. For example:
- disabling mxisd (`matrix_mxisd_enabled: false`), causes Synapse
and riot-web to reconfigure themselves with other (public)
Identity servers.

- enabling matrix-corporal (`matrix_corporal_enabled: true`) affects
how reverse-proxying (by `matrix-nginx-proxy`) is done, in order to
put matrix-corporal's gateway server in front of Synapse

We may be able to move away from such dependencies in the future,
at the expense of a more complicated manual configuration, but
it's probably not worth sacrificing the convenience we have now.

As part of this work, the way we do "start components" has been
redone now to use a loop, as suggested in #65 (Github issue).
This should make restarting faster and more reliable.