add matrix_synapse_redis_dbid var

This new version makes the mail spool persistent, so that exim can be
restarted without losing queued messages.

chore(deps): update dependency backup_borg to v1.2.8-1.8.9-0

Ref: 0e05a332db (commitcomment-140240527)

Only `amd64` and `arm64` actually work.

The KeyDB role includes a validation task and will complain about
unsupported architectures (like `arm32`).

`arm32` users can stick to Redis for now (`keydb_enabled: false` + `redis_enabled: true`) until:
- the KeyDB role starts supporting self-building.. although building such large
  projects on weak CPUs is probably impractical
- a prebuilt arm32 image is made available by other means

This reverts commit 9c01d875f3.

This is very confusing and messy.. but it's documented.
`ansible_become_*` variables actually take priority and override all `become_*`
variables set at the task level.

As such, using `ansible_become=true ansible_become_user=root` in
`inventory/hosts` causes issues because tasks that specify
`become: OTHER_USER` will be forced to run as `root` due to
`ansible_become_user`.

chore(deps): update dependency redis to v7.2.4-0

* add keydb as redis replacement

* sort requirements

For some of these, the `ansible_` prefix does not seem to be needed,
but it's the canonical way to do things and it may become required in
newer Ansible versions.

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

Improve Pantalaimon Support in Draupnir and add Mjolnir support

chore(deps): update gnuxie/draupnir docker tag to v1.87.0

Pin Draupnir Appservice to 1.87.0 instead of Develop & update Draupnir at the same time to the same version.

Appservice Draupnir for All required Develop before the release of 1.87.0 to work at all in the playbook. Now that we have a release to pin to we will return to being pinned to a release. Especially as Draupnir 2.0.0 push is happening now in main. This will mean that Draupnir develop is expected to be much more unstable than usual for a bit so its important that we pin to a stable release. These releases are validated due to having been dogfooded ever since D4A was merged into the playbook.

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3218

commit cf8637efac
Author: Slavi Pantaleev <slavi@devture.com>
Date:   Sun Mar 24 19:14:57 2024 +0200

    Make devture_systemd_docker_base_ipv6_enabled automatically reconfigure geerlingguy/ansible-role-docker

    Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3218

commit dc7af3bc7d
Author: Slavi Pantaleev <slavi@devture.com>
Date:   Sun Mar 24 19:10:31 2024 +0200

    Replace matrix_ipv6_enabled with devture_systemd_docker_base_ipv6_enabled

    Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3218

commit 07e900d6a2
Author: Slavi Pantaleev <slavi@devture.com>
Date:   Sun Mar 24 19:01:51 2024 +0200

    Improve matrix_ipv6_enabled comments

commit 3f03ca7f69
Author: Tilo Spannagel <development@tilosp.de>
Date:   Sat Mar 9 19:27:50 2024 +0000

    Add setting to enable ipv6

This is actually authored by Julian Foad here
(https://lab.trax.im/matrix/matrix-docker-ansible-deploy), but was in
need of a rebase and various adjustments caused by huge playbook
refactoring that landed in the past months.

This rework is completely untested.

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

feat: Add global option to configure all bridges encryption default

Signed-off-by: gardar <gardar@users.noreply.github.com>

Signed-off-by: gardar <gardar@users.noreply.github.com>

Upgrade Jitsi (v9364-0 -> v9364-1)

chore(deps): update matrixdotorg/sygnal docker tag to v0.14.0

Ref: 2fb5d77781

Possible fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/3231

Fix D4A Documentation ommiting that your bot needs to have sufficient Powerlevel to write to the policy list that is its management room.

In the process of writing the Draupnir for all role documentation it was forgotten that Draupnir needs to have the ability to write to the main management room policy list that controls who can access the bot. This flaw was overlooked during development as naturally without thinking the bot had these powers.

Upstream Docs had this exact bug also and the author of this commit will have to go and fix upstream docs also to resolve this bug.