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

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

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.

> WARNING: Error loading config file: .dockercfg: $HOME is not defined

.. which appeared in Docker 20.10.

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

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/737

I feel like timers are somewhat more complicated and dirty (compared to
cronjobs), but they come with these benefits:

- log output goes to journald
- on newer systemd distros, you can see when the timer fired, when it
will fire, etc.
- we don't need to rely on cron (reducing our dependencies to just
systemd + Docker)

Cronjobs work well, but it's one more dependency that needs to be
installed. We were even asking people to install it manually
(in `docs/prerequisites.md`), which could have gone unnoticed.

Once in a while someone says "my SSL certificates didn't renew"
and it's likely because they forgot to install a cron daemon.

Switching to systemd timers means that installation is simpler
and more unified.

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.

We were only defining this in `group_vars/matrix_servers`, which is
inconsistent with how we normally do things.

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

Fixes #586 (Github Issue)

`matrix_container_images_self_build` was not really doing anything
anymore. It previously was influencing `matrix_*_self_build` variables,
but it's no longer the case since some time ago.

Individual `matrix_*_self_build` variables are still available.
People that would like to toggle self-building for a specific component
ought to use those.

These variables are also controlled automatically (via
`group_vars/matrix_servers`) depending on `matrix_architecture`.

In other words, self-building is being done automatically for
all components when they don't have a prebuilt image for the specified
architecture. Some components only support `amd64`, while others also
have images for other architectures.

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

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

Related to #542 (Github Issue).

Fixes #523 (Github Issue).