All homeserver implementations have been updated to support this as
well.

It's just Jitsi that possibly doesn't work with anything other than `auth-secret`.

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

We're casting everything it `int`, but since Jinja templates are
involved, these values end up as strings anyway.

Doing `| int | to_json` is good, but we should only cast numbers to
integer, not empty strings, as that (0) may be interpreted differently
by Synapse.

To turn of auto-tuning, one is possibly supposed to pass empty strings:

> This option defaults to off, enable it by providing values for the sub-options listed below.

It could be that `0` is also considered "no value provided", but I
haven't verified that.

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

* Modify Synapse Cache Factor to use Auto Tune

Synapse has the ability to as it calls in its config auto tune caches.

This ability lets us set very high cache factors and then instead limit our resource use.

Defaults for this commit are 1/10th of what Element apparently runs for EMS stuff and matrix.org on Cache Factor and upstream documentation defaults for auto tune.

* Add vars to Synapse main.yml to control cache related config

This commit adds various cache related vars to main.yml for Synapse.

Some are auto tune and some are just adding explicit ways to control upstream vars.

* Updated Auto Tune figures

Autotuned figures have been bumped in consultation with other community members as to a reasonable level. Please note these defaults are more on the one of each workers side than they are on the monolith Side.

* Fix YML Error

The playbook is not happy with the previous state of this patch so this commit hopefully fixes it

* Add to_json to various Synapse tuning related configs

* Fix incorrect indication in homeserver.yaml.j2

* Minor cleanups

* Synapse Cache Autotuning Documentation

* Upgrade Synapse Cache Autotune to auto configure memory use

* Update Synapse Tuning docs to reflect automatic memory use configuration

* Fix Linting errors in synapses main.yml

* Rename variables for consistency (matrix_synapse_caches_autotuning_* -> matrix_synapse_cache_autotuning_*)

* Remove FIX ME comment about Synapse's `cache_autotuning`

`docs/maintenance-synapse.md` and `roles/custom/matrix-synapse/defaults/main.yml`
already contains documentation about these variables and the default values we set.

* Improve "Tuning caches and cache autotuning" documentation for Synapse

* Announce larger Synapse caches and cache auto-tuning

---------

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

Issues and Pull Requests were not migrated to the new
organization/repository, so `matrix-org/synapse/pull` and
`matrix-org/synapse/issues` references were kept as-is.

`matrix-org/synapse-s3-storage-provider` references were also kept,
as that module still continues living under the `matrix-org` organization.

This patch mainly aims to change documentation-related things, not actual
usage in full yet. For polish that, another more comprehensive patch is coming later.

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

Related to https://github.com/matrix-org/synapse/pull/15488

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

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

Related to:

- https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/2698
- https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/2700

* Update homeserver.yaml.j2

* Update configuring-playbook-ldap-auth.md

* Update homeserver.yaml.j2

* Add ability to disable password auth

* Allow disabling password authentication

Related to:

- https://github.com/matrix-org/synapse/pull/14551/files
- https://github.com/matrix-org/synapse/pull/14619/files

It's unnecessary when `pusher_instances` is populated.

Source: 6acb6d772a

It's unnecessary when `federation_sender_instances` is populated.

Source: 6acb6d772a

This paves the way for installing other roles into `roles/galaxy` using `ansible-galaxy`,
similar to how it's done in:

- https://github.com/spantaleev/gitea-docker-ansible-deploy
- https://github.com/spantaleev/nextcloud-docker-ansible-deploy

In the near future, we'll be removing a lot of the shared role code from here
and using upstream roles for it. Some of the core `matrix-*` roles have
already been extracted out into other reusable roles:

- https://github.com/devture/com.devture.ansible.role.postgres
- https://github.com/devture/com.devture.ansible.role.systemd_docker_base
- https://github.com/devture/com.devture.ansible.role.timesync
- https://github.com/devture/com.devture.ansible.role.vars_preserver
- https://github.com/devture/com.devture.ansible.role.playbook_runtime_messages
- https://github.com/devture/com.devture.ansible.role.playbook_help

We just need to migrate to those.

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.

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

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.