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.

https://github.com/vector-im/element-web/releases/tag/v1.9.3

See:
- https://github.com/vector-im/element-web/releases/tag/v1.8.4
- https://matrix.org/blog/2021/09/10/pre-disclosure-upcoming-critical-fix-for-several-popular-matrix-clients

Element web/desktop has just been updated to fix some regressions in regard to VoIP.

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

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

Related discussion here: 1ab507349c (commitcomment-51108407)

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

Signed-off-by: Ahmad Haghighi <haghighi@fedoraproject.org>

https://github.com/vector-im/element-web/releases/tag/v1.7.20
https://hub.docker.com/layers/vectorim/element-web/v1.7.20/images/sha256-44cae3a532d86c16940deb70866b522ba6acc8c5d7adf3c661cfc8b06f1de681?context=explore

These are just defensive cleanup tasks that we run.
In the good case, there's nothing to kill or remove, so they trigger an
error like this:

> Error response from daemon: Cannot kill container: something: No such container: something

and:

> Error: No such container: something

People often ask us if this is a problem, so instead of always having to
answer with "no, this is to be expected", we'd rather eliminate it now
and make logs cleaner.

In the event that:
- a container is really stuck and needs cleanup using kill/rm
- and cleanup fails, and we fail to report it because of error
suppression (`2>/dev/null`)

.. we'd still get an error when launching ("container name already in use .."),
so it shouldn't be too hard to investigate.