Signed-off-by: Sebastian Gumprich <github@gumpri.ch>

Related to https://github.com/jitsi/docker-jitsi-meet/issues/1377

Adding this doesn't really help though. `stable-7648-2` is broken
regardless. `stable-7648-3` is necessary to make it work.

We're already updated to `-3` anyway. This just adds the missing
environment variable for completeness.

This reverts commit 2c01c5bedf.

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

Related to https://github.com/jitsi/jitsi-meet/issues/12026

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.

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

fixes spantaleev/matrix-docker-ansible-deploy#1889

Support for arm64 images tracked in jitsi/docker-jitsi-meet#1214 and added in jitsi/docker-jitsi-meet#1269

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

Tested, works without any configuration changes.

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

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=

As of docker-jitsi-meet stable-6433 [1], `/config/interface_config.js`
is regenerated on every boot. The correct way to modify the interface
config is now via `/config/custom-interface_config.js`, which is
appended to a default copy of `interface_config.js` by
`/etc/cont-init.d/10-config` on every boot of the docker image.

Given that `interface_config.js` is considered deprecated by upstream
(all options will eventually be moved to `config.js`), we also deprecate
the `matrix_jitsi_web_interface_config_*` variables in favour of
`matrix_jitsi_web_custom_interface_config_extension`.

[1] https://github.com/jitsi/docker-jitsi-meet/blob/stable-6433/CHANGELOG.md#stable-6433

The domain is invalid with space, so it shouldn't be here

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

The check was checking for an empty string in `matrix_jitsi_prosody_auth_internal_accounts`,
which is unlikely to happen. We should check for an empty list instead.

The check was not validating username/password values, so telling the user that they need a non-empty
username/password is misleading. It was merely checking if there's at least one entry in the list.

This patch adjusts the check and message accordingly.

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.

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

Regresion since https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/1139