Also check if matrix_ssl_lets_encrypt_support_email is blank

Upgrade Etherpad (1.8.7 -> 1.8.12)

Another field with 'invalid input syntax for type smallint'

GoMatrixHosting v0.3.1 hotfix!

- removed build_database_list.yml

- add matrix_postgres_backup_databases to be build on top of matrix_postgres_additional_databases
- POSTGRES_DB is now directly set from matrix_postgres_backup_databases while building the templates/env-postgres-backup.j2

- adjusted env-postgres-backup.j2 to use the new role specific variables

matrix-awx - the GoMatrixHosting v0.3.0 initial PR

Added support for the Go-NEB bot

This may be especially helpful to existing playbook users
who happen to find themselves installing Go-NEB later on.

Updated Element 1.7.22 -> 1.7.23

matrix-nginx-proxy: specify Origin header, comply with CORS

Self-checks against the .well-known URIs look for the HTTP header
"Access-Control-Allow-Origin" indicating that the remode endpoint
supports CORS. But the remote server is not required to include
said header in the response if the HTTP request does not include
the "Origin" header. This is in accordance with the specification
[1] stating: 'A CORS request is an HTTP request that includes an
"Origin" header.'

This is in fact true for Gitlab pages hosting and that's why the
issue was identified.

Let's specify "Origin" header in the respective uri tasks performing
the HTTP request and ensure a CORS request.

[1] https://fetch.spec.whatwg.org/#http-requests

Adding vars to synapse for private servers

We have a flow like this:
1. matrix.DOMAIN vhost (matrix-domain.conf)
2. matrix-synapse vhost (matrix-synapse.conf); or matrix-corporal container, if enabled
3. (optional) matrix-synapse vhost (matrix-synapse.conf), if matrix-corporal enabled
4. matrix-synapse container

We are setting `X-Forwarded-For` correctly in step #1, but were
overwriting it in step #2 with something inaccurate.

Not doing anything in step #2 is better than doing the wrong thing.
It's probably best if we append another reverse-proxy address there
though, although what we're doing now (with this patch) seems to yield
the correct result (when matrix-corporal is not enabled).

When matrix-corporal is enabled, we still seem to do the wrong thing for
some reason. It's something to be fixed later on.

Make steps in configuring-playbook.md numbered

instead of bullet points which make it more difficult to tell whether or not you completed all of the steps

Adjust wait timeout

During first setup postgres takes its time to get up and running, resulting in "postgres in startup" exceptions from synapse if you run without additional services that come in between. Hence suggesting increasing the time a bit to avoid having an error which heals itself and thus is hard to spot for newcomers.