Regression since #681 (Github Pull Request).

Fixes #715 (Github Issue).

We'd like the roles to be self-contained (as much as possible).

Thus, the `matrix-nginx-proxy` shouldn't reference any variables from
other roles. Instead, we rely on injection via
`group_vars/matrix_servers`.

Related to #681 (Github Pull Request)

If `matrix_dynamic_dns_enabled`, we'd like to ensure there's at least
one configuration defined.

Related to #681 (Github Pull Request)

- `item` was undefined
- `'key' in configurations == ''` was doing the wrong thing

Related to #681 (Github Pull Request)

Having it unset in the role itself (while referencign it) is a little strange.

Now people can look at the `roles/matrix-dynamic-dns/defaults/main.yml`
file and figure out everything that's necessary to run the role.

Related to #681 (Github Pull Request)

This broke in 63a49bb2dc.

Proxying the OpenID Connect endpoints is now possible,
but needs to be enabled explicitly now.

Supersedes #702 (Github Pull Request).

This patch builds up on the idea from that Pull Request,
but does things in a cleaner way.

Fixes #696 (Github Issue)

We do this to match Synapse's new default "max_upload_size" (50MB).

This `matrix_nginx_proxy_proxy_matrix_client_api_client_max_body_size_mb`
default value only affects standalone usage of the `matrix-nginx-proxy`
role. When the role is used in the context of the playbook,
the value is dynamically assigned from `group_vars/matrix_servers`.

Somewhat related to #692 (Github Issue).

The regex introduced in 63a49bb2dc seems to take precedence
over the bare location blocks, causing a regression.

> It is important to understand that, by default, Nginx will serve regular expression matches in preference to prefix matches.
> However, it evaluates prefix locations first, allowing for the administer to override this tendency by specifying locations using the = and ^~ modifiers.

Source: https://www.digitalocean.com/community/tutorials/understanding-nginx-server-and-location-block-selection-algorithms

Fixes #685 (Github Issue).

If the SQLite database was from an older version of Synapse, it appears
that Synapse would try to run migrations on it first, before importing.
This was failing, because the file wasn't writable.

Hopefully, this fixes the problem.

Interestingly, no one has reported this failure before #662 (Github
Issue).

It doesn't make sense to keep saying that we support such old Ansible
versions, when we're not even testing on anything close to those.

Time is also passing and such versions are getting more and more
ancient. It's time we bumped our requirements to something that is more
likely to work.

I don't believe Ansible v1 would even go as far as executing this
sanity check, but.. Adding an extra defensive check for completeness.