People often report and ask about these "failures".
More-so previously, when the `docker kill/rm` output was collected,
but it still happens now when people do `systemctl status
matrix-something` and notice that it says "FAILURE".

Suppressing to avoid further time being wasted on saying "this is
expected".

* add borg backup

* lint fix

* add exlclude patterns

* missed in the #1726 fix for honoroit

* feedback

* Fix indentation

* feedback

* feedback

* feedback

Co-authored-by: Slavi Pantaleev <slavi@devture.com>

This reverts commit 0103d92df4.

The same fix has now been merged upstream
(https://gitlab.com/beeper/mx-puppet-monorepo/-/merge_requests/35), so
we don't need to use a fork anymore.

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

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

We're using a pinned commit of this fork, which patches up the npm/yarn
lock files, so that self-building of the Discord and Slack bridges can
work after GitHub's deprecation of the `git://` and `ssh://` protocols
(https://github.blog/2021-09-01-improving-git-protocol-security-github/).

When the issue gets fixed in the Beeper fork (via
https://gitlab.com/beeper/mx-puppet-monorepo/-/merge_requests/35 or
otherwise), we'll get back on it.

This switches the playbook from devture/rust-synapse-compress-state (a
container image which wraps the upstream-prebuilt amd64 binary of
rust-synapse-compress-state) to registry.gitlab.com/mb-saces/rust-synapse-compress-state
(https://gitlab.com/mb-saces/rust-synapse-compress-state), which builds
rust-synapse-compress-state from source and provides a multi-arch image
that currently works on amd64 and arm64.

Ideally, we'll stop using `:latest` and arm32 support will be made
available upstream as well at some point.
Discussed here: https://gitlab.com/mb-saces/rust-synapse-compress-state/-/issues/1

This makes it easier to use another container image for
rust-synapse-compress-state, which may be storing the binary at another
path.

This is a minor hotfix, needs to be bumped though or new deploys will break (existing deploys not affected by bug).

Changed the commit hash in matrix_synapse_ext_spam_checker_mjolnir_antispam_git_version to latest. Fixes a Synapse ImportError with mjolnir v1.4.1 leading to a Synapse crash-loop.

`roles/matrix-synapse/vars/workers.yml` has not been updated here,
because running `roles/matrix-synapse/files/workers-doc-to-yaml.awk`
seems to cause some trouble with the current `workers.md` file
available at https://github.com/matrix-org/synapse/raw/master/docs/workers.md,
namely lots of:

> FIXME: ADDITIONAL CONDITIONS REQUIRED: to be enabled manually

lines and commented out regex lines.

This is something that remains to be investigated/fixed.

For an unknown reason prometheus ignored the given "numeric" index and replaced it by 1. This made it not work properly, plus multiple workers of same types were not differentiable. With a "string" index, it works as intended.

The `to_nice_yaml` helper will by default wrap any string YAML values on
the first space after column 80. This can in worst case yield invalid
YAML syntax. More details in Ansible's documentation here:

https://docs.ansible.com/ansible/latest/user_guide/playbooks_filters.html#formatting-data-yaml-and-json

In short, you need to explicitly provide a custom width argument of a
high number of some kind to avoid the line wrapping.

Adding when clause to ma1sd image build task to avoid image being built if not needed.

matrix_synapse_federation_port_enabled can be disabled by users, for
example, when one wants to use the same port for client and federation
requests (docs/configuring-playbook-federation.md).

https://github.com/mautrix/facebook/issues/215

`matrix_nginx_proxy_enabled` is usually set to false by users, this is when
the warning should be displayed.

Fixup for d8a19e5bf9

Building mx-puppet-discord appears to have been broken for a while.

Related to:
- https://github.com/matrix-discord/mx-puppet-discord/issues/201
- https://github.com/matrix-discord/mx-puppet-discord/issues/202
- https://github.com/matrix-discord/mx-puppet-discord/issues/203

We'd rather use a fork that is maintained better and by someone who
cares about whether their software works or not, so we'll be using the
Beeper-maintained for from now on.

In the future, we should probably do the same for the Slack bridge
which is also part of the same monorepo
(https://gitlab.com/beeper/mx-puppet-monorepo).

Various roles depend on this. It makes sense to make it part
of the `matrix-base` role.