These Postgres configuration variables are part of the `database.yaml` file
and don't need to be here.

This allows people to augment the Synapse image with custom tools and
addons without having to rebuild it from scratch.

If customizations are enabled, the playbook will build a new
`localhost/matrixdotorg/synapse:VERSION-customized` image
on top of the default one (`FROM matrixdotorg/synapse:VERSION`)
and with custom Dockerfile build steps.

For servers that self-build the Synapse image, the Synapse image will be
built first, before proceding to extend it the same way.

In the future, we'll also have easy to enable Dockerfile build steps
for modules that the playbook supports.

In the future, we'll also inject media storage providers that we support
into the `matrix_synapse_media_storage_providers_auto` list.

This keeps the configuration cleaner and hopefully prevents odd issues
if Synapse (by any chance) happens to interpret `pusher_instances: []`
as "no pushers", instead of as "push from the master process".

I haven't confirmed what an empty pushers/federation-senders list means,
so it's safer to just avoid it.

.. although.. manual configuration is discouraged in most cases.

As stream writer workers are also powered by the `generic_worker`
Synapse app, this necessitated that we provide means for distinguishing
between them and regular `generic_workers`.

I've also taken the time to optimize nginx configuration generation
(more Jinja2 macro usage, less duplication).

Worker names have also changed.
Workers are now named sequentially like this:
- `matrix-synapse-worker-0-generic`
- `matrix-synapse-worker-1-stream-writer-typing`
- `matrix-synapse-worker-2-pusher`

instead of `matrix-synapse-worker_generic_worker-18111` (indexed with a
port number).

People who modify `matrix_synapse_workers_enabled_list` directly will
need to adjust their configuration.

We do the same everywhere else. This is an omission.

`frontend_proxy` workers have been superseded by `generic_worker` workers.
Related to https://github.com/matrix-org/synapse/pull/13645

This is done in anticipation of this option's removal in the
upcoming Synapse v1.66.0 release (likely tomorrow).

See: https://matrix-org.github.io/synapse/v1.66/upgrade.html#delegation-of-email-validation-no-longer-supported

* appservice: add and use matrix_homeserver_* vars

* appservice: use the new vars

* Apply suggestions from code review

Co-authored-by: Slavi Pantaleev <slavi@devture.com>

Co-authored-by: Slavi Pantaleev <slavi@devture.com>

Synapse no longer describes the stats as anonymized since the `server_name` is included.
https://github.com/matrix-org/synapse/pull/13321

Currently, Synapse workers ignore the X-Forwarded headers, which leads to internal Docker IP addresses randomly appearing in the users' device list.

This adds the `x_forwarded: true` option to the worker config, fixing the issue.

Fixup for 5eff67371d - https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/1884

Source: https://github.com/matrix-org/synapse/blob/v1.59.0/docs/upgrade.md#deprecation-of-the-synapseappappservice-and-synapseappuser_dir-worker-application-types

As an alternative, we should probably find a way to run one or a few
more generic workers (which will handle appservice and user_dir stuff) and
update `homeserver.yaml` so that it would point to the name of these workers using
`notify_appservices_from_worker` and `update_user_directory_from_worker` options.

For now, this solves the deprecation, so we can have a peace of mind
going forward.

We're force-setting these worker counts to 0, so that we can clean up
existing homeservers which use these worker types. In the future, these
options will either be removed or repurposed (so that they transparently
create more generic workers that handle user_dir/appservice loads).

When using LDAP simple bind, the `bind_dn` and `bind_password`
configuration values must not be present.

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

`roles/matrix-synapse/vars/workers.yml` has not been updated here,
because running `roles/matrix-synapse/files/workers-doc-to-yaml.awk`
seems to cause some trouble with the current `workers.md` file
available at https://github.com/matrix-org/synapse/raw/master/docs/workers.md,
namely lots of:

> FIXME: ADDITIONAL CONDITIONS REQUIRED: to be enabled manually

lines and commented out regex lines.

This is something that remains to be investigated/fixed.

The `to_nice_yaml` helper will by default wrap any string YAML values on
the first space after column 80. This can in worst case yield invalid
YAML syntax. More details in Ansible's documentation here:

https://docs.ansible.com/ansible/latest/user_guide/playbooks_filters.html#formatting-data-yaml-and-json

In short, you need to explicitly provide a custom width argument of a
high number of some kind to avoid the line wrapping.

matrix_synapse_federation_port_enabled can be disabled by users, for
example, when one wants to use the same port for client and federation
requests (docs/configuring-playbook-federation.md).

For now, we disable the new `com.devture.shared_secret_auth` login type
by default, because it causes problems with Element:
https://github.com/vector-im/element-web/issues/19605

This also becomes the first module to use the new Synapse module system
that got introduced in Synapse v1.46.0.

Despite these upgrades, things should remain functionally identical
as far as bridges, matrix-corporal or other consumers are concerned.

This also removes the `matrix_synapse_version_arm64` variable we've
been dragging around for a long time.

Since https://github.com/matrix-org/synapse/pull/11810, a multiarch Synapse
container image (for AMD64 and ARM64) is released at the same time.

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=

This commit simply add encryption_enabled_by_default_for_room_type
variable.

Signed-off-by: Alejo Diaz <xlejo@protonmail.com>

Related to https://github.com/matrix-org/synapse/issues/11604

Getting an upstream fix is preferable. In any case, it's probably nice
to have this defined explicitly in our configuration. This way, people
can more easily discover that they can override the URL preview
language.