Discussed here: https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/1510

We're trying to move away from implementation-specific variables,
hoping for a clean (implementation-neutral) examples/vars.yml file.

Doing this seems more reasonable and simpler.

The goal is to have a single variable which tells us which homeserver
software is in use. Much simpler than having if/elif/elif checks for
variables like (`matrix_synapse_enabled` and `matrix_dendrite_enabled`, etc.)
everywhere.

We recently had someone need to inject additional configuration into
`/.well-known/matrix/client` as described here:
22b245bbd1/docs/bigbluebutton.md (have-dimension-create-meetings-with-elements-video-call-button)

There may be other use cases as well.

#1192 lead to the following error for me on Archlinux:
`TASK [matrix-base : Install host dependencies] *******************************************************************************************************************************
fatal: [matrix.***.de]: FAILED! => changed=false 
  msg: |-
    failed to install systemd-timesyncd: error: target not found: systemd-timesyncd`

There is no package called `systemd-timesyncd` on Archlinux. The service is installed with the [`systemd`](https://archlinux.org/packages/core/x86_64/systemd/) package itself.

I suggest removing the `systemd-timesyncd` from 2453876eb9/roles/matrix-base/tasks/server_base/setup_archlinux.yml (L7)

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

This also simplifies Prerequisites, which is great.

It'd be nice if we were doing these checks in some optional manner
and reporting them as helpful messages (using
`matrix_playbook_runtime_results`), but that's more complicated.
I'd rather drop these checks completely.

Using the hardcoded IP did break while I was
messing with IPv6 stuff on the other branch

Future maintainer: check on https://docs.docker.com/engine/install/debian/ if Docker for
Debian 11 is released, then undo this commit

Fixup for https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/769

Related to 6e652e10ad

This also adds support for installing python3-docker (not python-docker)
in systems that run Python 3.

Raspbian doesn't seem to support arm64, so this is somewhat pointless
right now.

However, they might in the future. Doing this should also unify us
some more with `setup_debian.yml` with the ultimate goal of
eliminating `setup_raspbian.yml`.

It's likely installed by default, but it doesn't hurt to specify it.
It also makes us more the same with `setup_debian.yml`.

Well, `ubuntu` or `debian`, the same key is served right now,
so it doesn't really matter.

This seems cleaner and less prone to breakage though.

Until now, we've only supported non-amd64 on Raspbian.

Seems like there are now people running Debian/Ubuntu on ARM,
so we were forcing them into amd64 Docker packages.

I've gotten a report that this change fixes support
for Ubuntu Server 20.04 on RPi 4B.

The docker_network bug was fixed two years ago
This reverts commit 36658addcd.

Interestingly, no one has reported this failure before #662 (Github
Issue).

It doesn't make sense to keep saying that we support such old Ansible
versions, when we're not even testing on anything close to those.

Time is also passing and such versions are getting more and more
ancient. It's time we bumped our requirements to something that is more
likely to work.

I don't believe Ansible v1 would even go as far as executing this
sanity check, but.. Adding an extra defensive check for completeness.

Certain more-minimal Debian installations may not have
lsb-release installed, which makes the playbook fail.

We need lsb-release on Debian, so that ansible_lsb
could tell us if this is Debian or Raspbian.

AWS Debian marketplace image does not have gpg preinstalled

https://aws.amazon.com/marketplace/pp/B0859NK4HC?ref=cns_srchrow

TASK [matrix-base : Ensure Docker's APT key is trusted] *******************************************************************************************************************************************************
fatal: [matrix.domain.com]: FAILED! => {"changed": false, "msg": "Failed to find required executable gpg in paths: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"}

Closes #590

Fixes #586 (Github Issue)

Certain people organize their inventory in a different way
and we'd like to accommodate them.

Related to #542 (Github Issue).

Fixes #542 (Github Issues).

We don't really need to fail in such a spectactular way,
but it's probably good to do. It will only happen for people
who are defining their own user/group id, which is rare.

It seems like a good idea to tell them that this doesn't work
as they expect anymore and to ask them to remove these variables,
which otherwise give them a fake sense of hope.

Related to #486 (Github Pull Request).

If one runs the playbook with `--tags=setup-all`, it would have been
fine.

But running with a specific tag (e.g. `--tags=setup-riot-web`) would
have made that initialization be skipped, and the `matrix-riot-web` role
would fail, due to missing variables.

No migration steps should be required.

Should help with #300 (Github Issue).