Communicating via container URLs works, but the URL provided to
livekit-jwt-service as `LIVEKIT_URL` is also passed to the user later
and it must be a public one at that point.

It'd be great if livekit-jwt-service can be given 2 different URLs
(e.g. `LIVEKIT_URL` and `LIVEKIT_URL_PUBLIC`) and only announce the
public one to the user, but there's no support for this yet.

The new rate limits are more suitable for running Element Call.

Ref:

- 93ae2aed98/docs/self-hosting.md (a-matrix-homeserver)
- https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3562

Instead of trying to increase them conditionally only when Element Call
is enabled, it's simpler and good-enough to just increase them in all cases.

This is required by Element Call.

Ref:

- 93ae2aed98/docs/self-hosting.md (a-matrix-homeserver)
- https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3562

This is required by Element Call.

Ref:

- 93ae2aed98/docs/self-hosting.md (a-matrix-homeserver)
- https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3562

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

Related to:

- https://github.com/element-hq/element-web/pull/29471
- 16f9e7dd46

Newer Element Web versions allow for the nginx port to be
overriden, etc., and provide instructions for running in read-only mode.

This makes our custom `nginx.conf` patches unnecessary.

Passing the correct `ELEMENT_WEB_PORT` environment variable
also helps with future changes.

Another benefit of this (besides keeping closer to upstream
recommendations and the improved simplicity) is that:

- the container can run its entrypoint env-substitutions code now,
  without reporting errors

- IPv6 for nginx works, so `matrix-client-element:8080` is accessible
  via IPv6 on the container network now
  (this affects only for Traefik's communicaton with Element Web
  internally; public connectivity was handled by Traefik and IPv6 was
  available there even before)

Ref:

- 2052080d7d/docs/install.md (docker)
- https://github.com/element-hq/element-web/pull/28849
- https://github.com/element-hq/element-web/pull/28840

This reverts commit 178f7a9fff.

Element v1.11.95 doesn't seem to work. The container starts and is
unhealthy.

Until this is investigated and fixed, reverting.

Previously `https://example.com` and `https://example.com/` would be
redirected to `https://matrix.example.com`.

However, `https://example.com/?something` was not handled and was tried
to be served as a file by matrix-static-files for this base domain.

From now on, paths containing query strings will be handled as well
and the query string will be passed along.
Example: `https://example.com/?something` -> `https://matrix.example.com/?something`

Since nginx 1.27.3, we can make use of the `resolve` parameter for an `upstream`'s `server`,
to allow DNS resolution to happen continuously at runtime, not just once during startup.

Previously, this was not possible to do in an `upstream` block without
an nginx-plus subscription. Outside of an `upstream` block, we've used
and still use `set $backend ..` workarounds to get DNS resolution at
runtime, but now we can do it in `upstream` as well.

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

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