Based on mautrix-whatsapp, as that's what the bridge software is based on.

Debug logs are inappropriate for production use.

Fixes #1873

The same logs still go to the systemd journal.

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

Related to https://github.com/zeratax/matrix-registration/issues/93

This is a poor way to do things though. It may break again in the future.
matrix-registration is a poorly maintained project and should likely be removed from the playbook.

Now that https://github.com/digitalentity/matrix_encryption_disabler/pull/9
has been merged, we can get the module from there.

Continuation of 246c43be1e

Source: https://github.com/matrix-org/synapse/blob/v1.59.0/docs/upgrade.md#deprecation-of-the-synapseappappservice-and-synapseappuser_dir-worker-application-types

As an alternative, we should probably find a way to run one or a few
more generic workers (which will handle appservice and user_dir stuff) and
update `homeserver.yaml` so that it would point to the name of these workers using
`notify_appservices_from_worker` and `update_user_directory_from_worker` options.

For now, this solves the deprecation, so we can have a peace of mind
going forward.

We're force-setting these worker counts to 0, so that we can clean up
existing homeservers which use these worker types. In the future, these
options will either be removed or repurposed (so that they transparently
create more generic workers that handle user_dir/appservice loads).

* add `NOENCRYPTION` option
* fix race condition on thread start
* fix greetings messages
* updated deps

Line 10, which sets the tag to which docker version to pull was reverted from `v1.1.15` to latest. This gets the playbook working again

When using LDAP simple bind, the `bind_dn` and `bind_password`
configuration values must not be present.

Details here: https://docs.ansible.com/ansible/devel/porting_guides/porting_guide_6.html#id36

Basically:

```yaml
- name: Prior to 2.13
  debug:
    msg: '[1] + {{ [2] }}'

- name: 2.13 and forward
  debug:
    msg: '{{ [1] + [2] }}'
```

Interestingly, we had been using the new/safe syntax in lofs of places.

We were using the broken one in many others though. Hopefully all
instances were fixed by this patch.

This new version should be buildable on arm64.

See: https://github.com/matrix-org/matrix-hookshot/releases/tag/1.7.0

There's still no prebuild arm64 image, so we continue relying on
self-building there.

Related to https://gitlab.com/mx-puppet/discord/mx-puppet-discord/-/issues/117

Looks like the bridge is too quick to start and fails to initialize
itself by connecting to Synapse. It's mostly observed after a system
reboot, because Synapse (and everything else) is slower to start.

Once mx-puppet-discord fails to initialize itself, a "No relay found"
error will be observed any time you try to relay a Matrix message to
Discord. Relaying messages in the other direction (Discord to Matrix)
also fails.

With this workaround (longer delay on mx-puppet-discord startup), I
observe mx-puppet-discord working well, even after a full reboot.
Of course, a proper fix is preferable, instead of delaying by a magic
number of seconds.

CVE: https://security-tracker.debian.org/tracker/CVE-2022-1552
Source: https://www.postgresql.org/about/news/postgresql-143-137-1211-1116-and-1021-released-2449/
Postgres 9.6 upgrade (**not a CVE fix, 9.x still vulnerable**): https://www.postgresql.org/docs/release/9.6.24/

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/1829

It forwards to the correct place but might as well just update it to the current URL.

Now that v0.1.1 is out, which depends on the functional matrix-slack-parser
it works again.