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

I changed the conditional statement in prosody systemd template to bind the localhost port by default if people have set ```matrix_nginx_proxy_enabled == false ```.
Hopefully that should make it the default behaviour now.

Added:
 - Conditional localhost Port bindings for Jitsi Prosody systemd template
- Added variable to main.yml to allow overriding from vars.yml

Jitsi-meet enabled websockets by default, claiming better reliability.
Matrix-nginx-proxy configuration has been set up according to the
Prosody documentation: https://prosody.im/doc/websocket

Changelog:
https://github.com/jitsi/docker-jitsi-meet/blob/stable-5765-1/CHANGELOG.md

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

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

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

Mostly affects people who disable the integrated `matrix-nginx-proxy`.

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/456
and more specifically 4d62a75f6f.

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.