The companion role was tightly coupled to Synapse through shared tags, worker routing, and lifecycle ordering. Keeping them separate added coordination overhead without practical benefits, especially for parallelized execution.

This merges the role into matrix-synapse while keeping companion logic organized under dedicated reverse_proxy_companion task/template subdirectories.

Compatibility is preserved:
- matrix_synapse_reverse_proxy_companion_* variable names remain unchanged
- install/setup companion-specific tags remain available

Cross-role/global wiring is now in group_vars (matrix-synapse section), while role defaults provide sensible standalone defaults and self-wiring for Synapse-owned values.

* Enable Internal Admin API Access separately from Public access.

* Add Config variable for Draupnir Hijack command

And also make the internal admin API be automatically  activated when this capability is used.

* Apply suggestions from code review

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

* Further Refine Internal Admin API

* Add Non Worker Labels for Internal Admin API

* Variable Rename

* Add validation rules for Internal Synapse admin API

* Add Draupnir Admin API required config validation.

* Override `matrix_synapse_reverse_proxy_companion_container_labels_internal_client_synapse_admin_api_traefik_entrypoints` via group vars

* Wire `matrix_bot_draupnir_admin_api_enabled` to `matrix_bot_draupnir_config_admin_enableMakeRoomAdminCommand` in Draupnir's `defaults/main.yml`

* Remove unnecessary `matrix_bot_draupnir_admin_api_enabled` override from `group_vars/matrix_servers`

The same value is now (more appropriately) defined in Draupnir's `defaults/main.yml` file anyway.

* Add additional condition (`matrix_bot_draupnir_enabled`) for enabling `matrix_synapse_container_labels_internal_client_synapse_admin_api_enabled`

* Use a separate task for validating `matrix_bot_draupnir_admin_api_enabled` when `matrix_bot_draupnir_config_admin_enableMakeRoomAdminCommand`

The other task deals with checking for null and not-blank and can't handle booleans properly.

---------

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

Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>

This likely breaks QR code login for Synapse-worker setups.

See https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/3749

After some checking, it seems like there's `/_synapse/client/oidc`,
but no such thing as `/_synapse/oidc`.

I'm not sure why we've been reverse-proxying these paths for so long
(even in as far back as the `matrix-nginx-proxy` days), but it's time we
put a stop to it.

The OIDC docs have been simplified. There's no need to ask people to
expose the useless `/_synapse/oidc` endpoint. OIDC requires
`/_synapse/client/oidc` and `/_synapse/client` is exposed by default
already.

This moves the comments from being just in Jinja,
to actually ending up in the generated `labels` file,
which makes inspection of the final result easier.

Also, some new lines were added here and there to make labels
more legible.

The generated file may still include weird new-lines due to
various `if` statements yielding content or not, but that's not so ugly
anymore - now that we have proper start/end sections that are visible in
the final `labels` file.

We'd be adding integration with an internal Traefik entrypoint
(`matrix_playbook_internal_matrix_client_api_traefik_entrypoint`),
so renaming helps disambiguate things.

There's no need for deperecation tasks, because the old names
have only been part of this `bye-bye-nginx-proxy` branch and not used by
anyone publicly.

This also updates validation tasks and documentation, pointing to
variables in the matrix-synapse role which don't currently exist yet
(e.g. `matrix_synapse_container_labels_client_synapse_admin_api_enabled`).

These variables will be added soon, as Traefik labels are added to the
`matrix-synapse` role. At that point, the `matrix-synapse-reverse-proxy-companion` role
will be updated to also use them.