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

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

It's mostly due to Docker CE dropping its repositories (and support) for
Debian 9.
If one installs Docker manually (likely a package named `docker.io`), it
will likely still work.
In any case, Debian 9 is old and end-of-life now, so advertising support
for it is not productive.

Ubuntu ended support for 16.04 in April

It's an optional service, so we shouldn't bother most people with it.

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/682

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.

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

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

ma1sd requires the openid endpoints for certain functionality.
Example: 90b2b5301c/src/main/java/io/kamax/mxisd/auth/AccountManager.java (L67-L99)

If federation is disabled, we still need to expose these openid APIs on the
federation port.

Previously, we were doing similar magic for Dimension.
As per its documentation, when running unfederated, one is to enable
the openid listener as well. As per their recommendation, people
are advised to do enable it on the Client-Server API port
and use the `federationUrl` variable to override where the federation
port is (making federation requests go to the Client-Server API).

Because ma1sd always uses the federation port (unless you do some
DNS overwriting magic using its configuration -- which we'd rather not
do), it's better if we just default to putting the `openid` listener
where it belongs - on the federation port.

With this commit, we retain the "automatically enable openid APIs" thing
we've been doing for Dimension, but move it to the federation port instead.
We also now do the same thing when ma1sd is enabled.

Discussed in #669 (Github Issue).

Added Jitsi firewall ports

Fixes #396 (Github Issue).

Don't mention systemd-journald adjustment anymore, because
we've changed log levels to WARNING and Synapse is not chatty by default
anymore.

The "excessive log messages may get dropped on CentOS" issue no longer
applies to most users and we shouldn't bother them with it.

Feel free to reword but we have had a couple of issues created now asking about Raspberry Pi support.

Somewhat related to #213 (Github Pull Request).

We've been moving in the opposite direction for quite a long time.
All services should just leave logging to systemd's journald.

When using Let's Encrypt SSL certificates, a cronjob is set up to
automatically renew them. Though it does require a `cron`-compatible
program on the server.

This fixes the error that is caused by the `/etc/cron.d` directory
not existing and the `ansible-cron` module trying to write out a
file there -- without checking if the directory exists first.

After having multiple people report issues with retrieving
SSL certificates, we've finally discovered the culprit to be
Ansible 2.5.1 (default and latest version on Ubuntu 18.04 LTS).

As silly as it is, certain distributions ("LTS" even) are 13 bugfix
versions of Ansible behind.

From now on, we try to auto-detect buggy Ansible versions and tell the
user. We also provide some tips for how to upgrade Ansible or
run it from inside a Docker container.

My testing shows that Ansible 2.4.0 and 2.4.6 are OK.
All other intermediate 2.4.x versions haven't been tested, but we
trust they're OK too.

From the 2.5.x releases, only 2.5.0 and 2.5.1 seem to be affected.
Ansible 2.5.2 corrects the problem with `include_tasks` + `with_items`.