Before we potentially clone to that path, we'd better make sure it exists.

We also simplify `when` statements a bit.
Given that we're in `setup_install.yml`, we know that the bridge is enabled,
so there's no need to check for that.

This is a bit misleading, because the old Docker image
was tagged as `4.93.1`. There hasn't been a `4.93.1` version yet though.

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

Related to d5945c6e78

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.

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

Related to 6e652e10ad

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)

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.

Fixes a problem like this:
> File "/usr/lib/python3.8/site-packages/mautrix/bridge/e2ee.py", line 79, in __init__
> raise RuntimeError("Unsupported database scheme")

mautrix-python's e2ee.py module expects to find `postgres://` instead of
`postgresql://`.

This is 8b6174786b done right. There were many more fields
that we had to account for.

This makes the `sqlite://` URI match what we were using before
and what the config expects.

Our old (base-path -> data-path) SQLite migration can't work otherwise.

It's probably not necessary to keep it anymore, but since we still do,
at least we should take care to ensure it works.