Fedora 35 is:

- `ansible_os_family = 'RedHat'`
- `ansible_distribution_major_version = '35'`

Our RedHat checks against v7/v8 are really for RHEL derivatives (CentOS, Rockylinux,
AlmaLinux), but the same checks (by coincidence) apply for Fedora 35.

The problem is that `'35' > '7'` (comparing these as strings) is
`false`.

This patch makes sure that we always cast
`ansible_distribution_major_version` to an integer.

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

Not hardcoding 'CentOS' and using the OS family ('RedHat') instead,
we now behave better on Rockylinux and AlmaLinux, etc.

With that said, we may or may not fully support CentOS/Rockylinux/AlmaLinux v8 yet.
Certain things were improved in
https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/300.

v8 support is discussed here: https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/300
Certain things (firewalld?) may still be problematic. This patch does not try to address those.
If the remaining issues are confirmed to be fixed in the future, we can mark v8 as supported.

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.

Also get rid of `--tags=update-user-password` in the
`matrix-dendrite` role, as what we had doesn't work.

We may be able to do it with some Ansible helper or something else.
For now, we'll omit this feature.

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.

Seems like Ubuntu 18.04 does not have a dedicated `systemd-timesyncd` package, nor
does it include the `systemd-timesyncd` binary in the main `systemd` package.

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

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

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

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

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

These are just defensive cleanup tasks that we run.
In the good case, there's nothing to kill or remove, so they trigger an
error like this:

> Error response from daemon: Cannot kill container: something: No such container: something

and:

> Error: No such container: something

People often ask us if this is a problem, so instead of always having to
answer with "no, this is to be expected", we'd rather eliminate it now
and make logs cleaner.

In the event that:
- a container is really stuck and needs cleanup using kill/rm
- and cleanup fails, and we fail to report it because of error
suppression (`2>/dev/null`)

.. we'd still get an error when launching ("container name already in use .."),
so it shouldn't be too hard to investigate.

We don't have instantiated services anymore, nor
/etc/systemd/system/matrix-synapse.service.wants/ stuff.