Sync with upstream

Closes https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/755

Not sure if it breaks with them or not, but no other directive
uses quotes and the nginx docs show examples without quotes,
so we're being consistent with all of that.

Code was clean up and simplified to make it simpler and easier to
maintain. No features were modified.

The different configurations are now all lower case, for consistent
naming.

`matrix_nginx_proxy_ssl_config` is now called
`matrix_nginx_proxy_ssl_preset`. The different options for "modern",
"intermediate" and "old" are stored in the main.yml file, instead of
being hardcoded in the configuration files. This will improve the
maintainability of the code.

The "custom" preset was removed. Now if one of the variables is set, it
will use it instead of the preset. This will allow to mix and match more
easily, for example using all the intermediate options but only
supporting TLSv1.2. This will also provide better backward
compatibility.

Fix appservice-slack default db: nedb

That bridge only supports its own file-based database,
so preparing a Postgres database for it is pointless.

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

Related to 6e652e10ad

Drop the old workaround for an Ansible bug that has been fixed three years ago

Provoked by https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/743

Added a role for the bridge mautrix-signal

We try to only use console logging (going to journald) for everything,
instead of logging things twice (or more).

While it's kind of nice having it, it's also somewhat raw
and unnecessary.

Having a good default and not even mentioning it seems better
for most users.

People who need a more exposed bridge (rare) can use
override the default configuration using
`matrix_mautrix_signal_configuration_extension_yaml`.

The answer to these is: it's good to have them in both places.
The role defines the obvious things it depends on (not knowing
what setup it will find itself into), and then
`group_vars/matrix_servers` "extends" it based on everything else it
knows (the homeserver being Synapse, whether or not the internal
Postgres server is being used, etc.)

We used to store them in data/, but that seems inappropriate,
since it's just static configuration that the playbook can recreate.

Keeps up with a1f64f5159 (diff-0ccf69eb4d59a7645eb4d0a0b077e693948edb33ad06df043bba3fb30122879b)

Example Files for Caddy2

Check for buggy version of Ansible that Ubuntu 20.04 provides

We need to suppress systemd service-stopping requests in certain rare
cases like https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/771

That issue seems to describe a case, where a migration from mxisd to
ma1sd was happening (DB files had just been moved), and then we were
attemping to stop `matrix-ma1sd.service` so we could import that database into
Postgres. However, there's neither `matrix-mxisd.service`, nor
`matrix-ma1sd.service` after `migrate_mxisd.yml` had just run, so
stopping `matrix-ma1sd.service` was failing.

We've had people who get the impression that well-known = bad,
DNS SRV = good, and who try to use DNS SRV for server delegation.

While it's true that DNS SRV can be superior for high-availability
scenarios, it's much harder to set up and comes with its own potential
downsides.

Using the well-known method is more straightforward and is enough
for almost all of us. Throwing people into the deep for no good
reason is not nice. Hopefully wording is better after this patch.

Merge