.. to mitigate log noise - WARNING:
Failed to listen on 0.0.0.0, continuing because listening on [::]

As seen on TV:
https://github.com/matrix-org/synapse/blob/master/docs/metrics-howto.md#monitoring-workers

(until https://github.com/matrix-org/synapse/issues/8787 is resolved)

Many people probably didn't even know this - that ansible can be
quite a bit picky about what it will be willing to work with remotely.

Thanks @maxklenk !

Thanks @maxklenk !

Continuation of 1fca917ad1.

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

`-v` magically creates the source destination as a directory,
if it doesn't exist already. We'd like to avoid this magic
and the potential breakage that it might cause.

We'd rather fail while Docker tries to find things to `--mount`
than have it automatically create directories and fail anyway,
while having contaminated the filesystem.

There's a lot more `-v` instances remaining to be fixed later on.
This is just some start.

Things like `matrix_synapse_container_additional_volumes` and
`matrix_nginx_proxy_container_additional_volumes` were not changed to
use `--mount`, as options for each one are passed differently
(`ro` is `ro`, but `rw` doesn't exist and `slave` is `bind-propagation=slave`).
To avoid breaking people's custom volume mounts, we keep it as it is for now.

A deficiency with `--mount` is that it lacks the `z` option (SELinux
ownership changes), and some of our `-v` instances use that. I'm not
sure how supported SELinux is for us right now, but it might be,
and breaking that would not be a good idea.

Related to #724 (Github Pull Request)

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

This patch makes us use more fully-qualified container image names
(either prefixed with docker.io/ or with localhost/).

The latter happens when self-building is enabled.

We've recently had issues where if an image was removed manually
and the service was restarted (making `docker run` fetch it from Docker Hub, etc.),
we'd end up with a pulled image, even though we're aiming for a self-built one.
Re-running the playbook would then not do a rebuild, because:
- the image with that name already exists (even though it's something
else)
- we sometimes had conditional logic where we'd build only if the git
repo changed

By explicitly changing the name of the images (prefixing with localhost/),
we avoid such confusion and the possibility that we'd automatically pul something
which is not what we expect.

Also, I've removed that condition where building would happen on git
changes only. We now always build (unless an image with that name
already exists). We just force-build when the git repo changes.

(quoting ftw)

(allegedly breaks with SSO enabled)

(yes, a bit awkward and brittle… xD)

also, worker.yaml.j2:
  - hone worker_name
  - remove worker_pid_file entry (would only be used if worker_daemonize
    set to true; also, synapse only knows about the container namespace
    and thus can not provide the required host-view PID)

& restrict federation listener; frontend_proxy / user_dir don't need it

.. alphabetically and put those not documented as multi-instance
capable on ports ending on zero.

Is the PID magic gonna work? or will it need an ExecStartPost hack..

- cherry-pick "Ensure worker config exists in systemd service (#7528)"
  from synapse d74cdc1a42e8b487d74c214b1d0ca575429d546a:
  "check that the worker config file exists instead of silently failing."

Fixes #586 (Github Issue)

Fixes #579 (Github Issue).