This is a security relevant update

This mostly fixes `key-order` warnings around
`block` statements.

Regression since the mass-replace in 34cdaade0.

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

Reference: https://ansible-lint.readthedocs.io/en/latest/default_rules/#var-naming

We don't really fix these, but just suppress them,
because they're like that intentionally.

We try to name variables in a way that is consistent with the
configuration key they control. If the upstream component uses
camelCase, we also need to include camelCase in the variable name.

Reference: https://ansible-lint.readthedocs.io/en/latest/default_rules/#git-latest

Our variable naming is not necessarily consistent across roles.
I've tried to follow the naming conventions of each individual role.
All new variables are suffixed with `_version`, but the prefix may be
somewhat different.

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

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

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

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".

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

Reverts b1b4ba501fdfaa, 90c9801c560b6, a3c84f78ca9c65a, ..

I haven't really traced it (yet), but on some servers, I'm observing
`ansible-playbook ... --tags=start` completing very slowly, waiting
to stop services. I can't reproduce this on all Matrix servers I manage.
I suspect that either the systemd version is to blame or that some
specific service is not responding well to some `docker kill/rm` command.

`ExecStop` seems to work great in all cases and it's what we've been
using for a very long time, so I'm reverting to that.

ExecStopPost should allow us to clean up (docker kill + docker rm)
even if the ExecStart (docker run ..) command failed, and not just after
a graceful service stop was initiated.

Source: https://www.freedesktop.org/software/systemd/man/systemd.service.html#ExecStopPost=

Ref: https://matrix.org/blog/2021/12/13/disclosure-buffer-overflow-in-libolm-and-matrix-js-sdk

Until now, we were leaving services "enabled"
(symlinks in /etc/systemd/system/multi-user.target.wants/).

We clean these up now. Broken symlinks may still exist in older
installations that enabled/disabled services. We're not taking care
to fix these up. It's just a cosmetic defect anyway.

We were applying the low-memory system patch to webpack.config.js
on systems with < 4GB memory.

From now on, we also let people force-enable patching by toggling the
`matrix_client_element_container_image_self_build_low_memory_system_patch_enabled`
variable.

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

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

Should have been done in 63f5a88fa0.