ma1sd 2.4.0 announced experimental support for arm64.
We're making use of those arm64 images instead of self-building.

Fixes #523 (Github Issue).

Related to #529 (Github Issue).

added docs, added seperate service for database, pr comments

We can undo this once https://github.com/ma1uta/ma1sd/issues/44 gets
resolved.

Fixes #494 (Github Issue).

the changes are necessary because certbot images are tagged, so docker does not recognize the necessary architecture

Discussed in #446 (Github Pull Request).

Fixes an error like this:

> synapse.config._base.ConfigError: Cannot reuse as_token across application services

turn tls port update

This will not work yet, as no version of Riot currently supports it.
It's expected to land in riot-web v1.5.16 via matrix-org/matrix-react-sdk#4348.

Hopefully fixes an error like this (which I haven't been able to
reproduce, but..):

> [modules/xmpp/strophe.util.js] <Object.i.Strophe.log>:  Strophe: Error: Failed to construct 'RTCPeerConnection': 'matrix.DOMAIN' is not one of the supported URL schemes 'stun', 'turn' or 'turns'.

These are some new defaults that we switch to, to follow upstream
changes:

- https://github.com/jitsi/docker-jitsi-meet/commit/264df04
- 3121494d4b

We do this for 2 reasons:

- so we can control things which are not controllable using environment
variables (for example `stunServers` in jitsi/web, since we don't wish
to use the hardcoded Google STUN servers if our own Coturn is enabled)

- so playbook variable changes will properly rebuild the configuration.
When using Jitsi environment variables, the configuration is only built
once (the first time) and never rebuilt again. This is not the
consistent with the rest of the playbook and with how Ansible operates.
We're not perfect at it (yet), because we still let the Jitsi containers
generate some files on their own, but we are closer and it should be
good enough for most things.

Related to #415 (Github Pull Request).

This keeps the roles cleaner and more independent of matrix-base,
which may be important for people building their own playbook
out of the individual roles and not using the matrix-base role.

In relation to #392 (Github Issue)

Related to #355.

Can you double check that the way I have this set only exposes it locally? It is important that the manhole is not available to the outside world since it is quite powerful and the password is hard coded.

Well, `config.yaml` has been playbook-managed for a long time.
It's now extended to match the default sample config of the Discord
bridge.

With this patch, we also make `registration.yaml` playbook-managed,
which leads us to consistency with all other bridges.

Along with that, we introduce `./config` and `./data` separation,
like we do for the other bridges.