We've had that logic in 2 places so far, leading to duplication
and a maintenance burden.

In the future, we'll also have an import-postgres feature,
which will also need Postgres version detection,
leading to more benefit from that logic being reusable.

We always skip at least one of these tasks, depending on which
SSL retrieval method is enabled, so it could have been confusing why.

Fix for d28bdb3258.

We were only supposed to install openssl when the self-signed
SSL certificate retrieval method is used, not always.

If uppercase is used, certain tools (like certbot) would cause trouble.
They would retrieve a certificate for the lowercased domain name,
but we'd try to use it from an uppercase-named directory, which will
fail.

Besides certbot, we may experience other trouble too.
(it hasn't been investigated how far the breakage goes).

To fix it all, we lowercase `host_specific_hostname_identity` by default,
which takes care of the general use-case (people only setting that
and relying on us to build the other domain names - `hostname_matrix`
and `hostname_riot`).

For others, who decide to override these other variables directly
(and who may work around us and introduce uppercase there directly),
we also have the sanity-check tool warn if uppercase is detected
in any of the final domains.

Fix for d28bdb3258

Adds support for managing certificates manually and for
having the playbook generate self-signed certificates for you.

With this, Let's Encrypt usage is no longer required.

Fixes Github issue #50.

It looks like SELinux can be left running without any (so far) negative
effects on our Matrix services.

There's no need to use `:z` or `:Z` options when mounting volumes either.
This means that files we create are labeled with a default context
(which may not be ideal if we only want them used from containers),
but it's compatible and doesn't cause issues.

Relabelling files is probably something we wish to stay away from,
especially for things like the media store, which contains lots of
files and is possibly on a fuse-mounted (S3/goofys) filesystem.

This is described in Github issue #58.

Until now, we had the variable, but if you redefined it, you'd run
into multiple problems:

- we actually always mounted some "storage" directory to the Synapse
container. So if your media store is not there, you're out of luck

- homeserver.yaml always hardcoded the path to the media store,
as a directory called "media-store" inside the storage directory.

Relocating to outside the storage directory was out of the question.

Moreover, even if you had simply renamed the media store directory
(e.g. "media-store" -> "media_store"), it would have also caused trouble.

With this patch, we mount the media store's parent to the Synapse container.
This way, we don't care where the media store is (inside storage or
not). We also don't assume (anymore) that the final part of the path
is called "media-store" -- anything can be used.

The "storage" directory and variable (`matrix_synapse_storage_path`)
still remain for compatibility purposes. People who were previously
overriding `matrix_synapse_storage_path` can continue doing so
and their media store will be at the same place.

The playbook no longer explicitly creates the `matrix_synapse_storage_path` directory
though. It's not necessary. If the media store is specified to be within it, it will
get created when the media store directory is created by the playbook.

* Add default template file for homepage HTML
* Add default riot-web config options for homepage

This makes it more consistent with other usage throughout the playbook.

Pretty much all variables live in their own `matrix_<whatever>`
prefix now and are grouped closer together in the default
variables file (`roles/matrix-server/defaults/main.yml`).