Bumps the dev-deps group with 1 update in the /deps/rabbit/test/amqp_jms_SUITE_data directory: [org.junit.jupiter:junit-jupiter-engine](https://github.com/junit-team/junit5).
Bumps the dev-deps group with 1 update in the /deps/rabbitmq_auth_backend_http/examples/rabbitmq_auth_backend_spring_boot directory: [org.junit.jupiter:junit-jupiter-params](https://github.com/junit-team/junit5).
Bumps the dev-deps group with 1 update in the /deps/rabbitmq_mqtt/test/java_SUITE_data directory: [org.junit.jupiter:junit-jupiter](https://github.com/junit-team/junit5).
Bumps the dev-deps group with 2 updates in the /deps/rabbitmq_stream/test/rabbit_stream_SUITE_data directory: [org.junit.jupiter:junit-jupiter-engine](https://github.com/junit-team/junit5) and [org.junit.jupiter:junit-jupiter-params](https://github.com/junit-team/junit5).
Bumps the dev-deps group with 2 updates in the /deps/rabbitmq_stream_management/test/http_SUITE_data directory: [org.junit.jupiter:junit-jupiter-engine](https://github.com/junit-team/junit5) and [org.junit.jupiter:junit-jupiter-params](https://github.com/junit-team/junit5).


Updates `org.junit.jupiter:junit-jupiter-engine` from 5.12.0 to 5.12.1
- [Release notes](https://github.com/junit-team/junit5/releases)
- [Commits](junit-team/junit-framework@r5.12.0...r5.12.1)

Updates `org.junit.jupiter:junit-jupiter-params` from 5.12.0 to 5.12.1
- [Release notes](https://github.com/junit-team/junit5/releases)
- [Commits](junit-team/junit-framework@r5.12.0...r5.12.1)

Updates `org.junit.jupiter:junit-jupiter` from 5.12.0 to 5.12.1
- [Release notes](https://github.com/junit-team/junit5/releases)
- [Commits](junit-team/junit-framework@r5.12.0...r5.12.1)

Updates `org.junit.jupiter:junit-jupiter-engine` from 5.12.0 to 5.12.1
- [Release notes](https://github.com/junit-team/junit5/releases)
- [Commits](junit-team/junit-framework@r5.12.0...r5.12.1)

Updates `org.junit.jupiter:junit-jupiter-params` from 5.12.0 to 5.12.1
- [Release notes](https://github.com/junit-team/junit5/releases)
- [Commits](junit-team/junit-framework@r5.12.0...r5.12.1)

Updates `org.junit.jupiter:junit-jupiter-params` from 5.12.0 to 5.12.1
- [Release notes](https://github.com/junit-team/junit5/releases)
- [Commits](junit-team/junit-framework@r5.12.0...r5.12.1)

Updates `org.junit.jupiter:junit-jupiter-engine` from 5.12.0 to 5.12.1
- [Release notes](https://github.com/junit-team/junit5/releases)
- [Commits](junit-team/junit-framework@r5.12.0...r5.12.1)

Updates `org.junit.jupiter:junit-jupiter-params` from 5.12.0 to 5.12.1
- [Release notes](https://github.com/junit-team/junit5/releases)
- [Commits](junit-team/junit-framework@r5.12.0...r5.12.1)

Updates `org.junit.jupiter:junit-jupiter-params` from 5.12.0 to 5.12.1
- [Release notes](https://github.com/junit-team/junit5/releases)
- [Commits](junit-team/junit-framework@r5.12.0...r5.12.1)

---
updated-dependencies:
- dependency-name: org.junit.jupiter:junit-jupiter-engine
  dependency-type: direct:development
  update-type: version-update:semver-patch
  dependency-group: dev-deps
- dependency-name: org.junit.jupiter:junit-jupiter-params
  dependency-type: direct:development
  update-type: version-update:semver-patch
  dependency-group: dev-deps
- dependency-name: org.junit.jupiter:junit-jupiter
  dependency-type: direct:development
  update-type: version-update:semver-patch
  dependency-group: dev-deps
- dependency-name: org.junit.jupiter:junit-jupiter-engine
  dependency-type: direct:development
  update-type: version-update:semver-patch
  dependency-group: dev-deps
- dependency-name: org.junit.jupiter:junit-jupiter-params
  dependency-type: direct:development
  update-type: version-update:semver-patch
  dependency-group: dev-deps
- dependency-name: org.junit.jupiter:junit-jupiter-params
  dependency-type: direct:development
  update-type: version-update:semver-patch
  dependency-group: dev-deps
- dependency-name: org.junit.jupiter:junit-jupiter-engine
  dependency-type: direct:development
  update-type: version-update:semver-patch
  dependency-group: dev-deps
- dependency-name: org.junit.jupiter:junit-jupiter-params
  dependency-type: direct:development
  update-type: version-update:semver-patch
  dependency-group: dev-deps
- dependency-name: org.junit.jupiter:junit-jupiter-params
  dependency-type: direct:development
  update-type: version-update:semver-patch
  dependency-group: dev-deps
...

Signed-off-by: dependabot[bot] <support@github.com>

Before the client authenticates, the standard
frame_max is not used. Instead, the limit is
a special constant.

This is fine for password or x.509 certificate-based
authentication but not for some JWT tokens,
which can vary in size, and take multiple
kilobytes.

8 kB specifically is the default HTTP header
length limit used by Nginx.
Sounds like this value was good enough
for a lot of Bearer headers with JWT tokens.

Closes #13541.

References #13541

Erlang 27 is fully supported in main and v4.1.x. Support for Erlang 26
in v4.1 remains. It's better to "drop" erlang 26 from CI because, at the
moment, our PRs and commits to main trigger about 270 jobs. If we just
add '27' to the matrix, we would spawn ~216 more jobs, totalling around
496 jobs per PR and commit to main. That's simply too much, because it's
reaching the usage limits of Github Actions [1], namely the 256 limit of
matrix jobs.

[1]
https://docs.github.com/en/actions/administering-github-actions/usage-limits-billing-and-administration#usage-limits

Prior to this change, we built the OCI for almost any change. That
doesn't make sense. For example, when there were changes to CI, it
didn't make because RabbitMQ had not changed.

CI will now build dev OCI images when there are actual code changes, or
changes to rabbit dependencies.

References #13541

References #13537.

 ## What?

If a TLS client app is misconfigured trying to connect to AMQP port 5672
instead to the AMQPS port 5671, this commit makes RabbitMQ log a more
descriptive error message.

```
openssl s_client -connect localhost:5672 -tls1_3
openssl s_client -connect localhost:5672 -tls1_2
```

RabbitMQ logs prior to this commit:
```
[info] <0.1073.0> accepting AMQP connection [::1]:53535 -> [::1]:5672
[error] <0.1073.0> closing AMQP connection <0.1073.0> ([::1]:53535 -> [::1]:5672, duration: '0ms'):
[error] <0.1073.0> {bad_header,<<22,3,1,0,192,1,0,0>>}

[info] <0.1080.0> accepting AMQP connection [::1]:53577 -> [::1]:5672
[error] <0.1080.0> closing AMQP connection <0.1080.0> ([::1]:53577 -> [::1]:5672, duration: '1ms'):
[error] <0.1080.0> {bad_header,<<22,3,1,0,224,1,0,0>>}
```

RabbitMQ logs after this commit:
```
[info] <0.969.0> accepting AMQP connection [::1]:53632 -> [::1]:5672
[error] <0.969.0> closing AMQP connection <0.969.0> ([::1]:53632 -> [::1]:5672, duration: '0ms'):
[error] <0.969.0> {detected_unexpected_tls_header,<<22,3,1,0,192,1,0,0>>

[info] <0.975.0> accepting AMQP connection [::1]:53638 -> [::1]:5672
[error] <0.975.0> closing AMQP connection <0.975.0> ([::1]:53638 -> [::1]:5672, duration: '1ms'):
[error] <0.975.0> {detected_unexpected_tls_header,<<22,3,1,0,224,1,0,0>>}
```

 ## Why?

I've seen numerous occurrences in the past few years where misconfigured TLS apps
connected to the wrong port. Therefore, RabbitMQ trying to detect a TLS client
and providing a more descriptive log message seems appropriate to me.

 ## How?

The first few bytes of any TLS connection are:

Record Type (1 byte):
Always 0x16 (22 in decimal) for a Handshake message.

Version (2 bytes):
This represents the highest version of TLS that the client supports. Common values:
0x0301 → TLS 1.0 (or SSL 3.1)
0x0302 → TLS 1.1
0x0303 → TLS 1.2
0x0304 → TLS 1.3

Record Length (2 bytes):
Specifies the length of the following handshake message.

Handshake Type (1 byte, usually the 6th byte overall):
Always 0x01 for ClientHello.

It also happens from time to time that HTTP clients use the wrong port
5672. Like for TLS clients connecting to 5672, RabbitMQ now prints a
more descriptive log message.

For example
```
curl http://localhost:5672
```
will log
```
[info] <0.946.0> accepting AMQP connection [::1]:57736 -> [::1]:5672
[error] <0.946.0> closing AMQP connection <0.946.0> ([::1]:57736 -> [::1]:5672, duration: '1ms'):
[error] <0.946.0> {detected_unexpected_http_header,<<"GET / HT">>}
```

We only check here for GET and not for all other HTTP methods, since
that's the most common case.

This avoids using Mix while compiling which simplifies
a number of things and let us do further build improvements
later on.

Elixir is only enabled from within rabbitmq_cli currently.

Eunit is disabled since there are only Elixir tests.

Dialyzer will force-enable Elixir in order to process
Elixir-compiled beam files.

This commit also includes a few changes that are
related:

 * The Erlang distribution will now be started for parallel-ct

 * Many unnecessary PROJECT_MOD lines have been removed

 * `eunit_formatters` has been removed, it provides little value

 * The new `maybe_flock` Erlang.mk function is used where possible

 * Build test deps when testing rabbitmq_cli (Mix won't do it anymore)

 * rabbitmq_ct_helpers now use the early plugins to have Dialyzer
   properly set up

This is a follow up to #13559 addressing the feedback in
#13559 (comment)

The improved logs look as follows:
```
openssl s_client -connect localhost:5672 -tls1_3

[info] <0.946.0> accepting AMQP connection [::1]:49321 -> [::1]:5672
[error] <0.946.0> closing AMQP connection [::1]:49321 -> [::1]:5672 (duration: '0ms'):
[error] <0.946.0> TLS client detected on non-TLS AMQP port. Ensure the client is connecting to the correct port.
```

```
curl http://localhost:5672

[info] <0.954.0> accepting AMQP connection [::1]:49402 -> [::1]:5672
[error] <0.954.0> closing AMQP connection [::1]:49402 -> [::1]:5672 (duration: '0ms'):
[error] <0.954.0> HTTP GET request detected on AMQP port. Ensure the client is connecting to the correct port
```

```
telnet localhost 5672
Trying ::1...
Connected to localhost.
Escape character is '^]'.
hello

[info] <0.946.0> accepting AMQP connection [::1]:49664 -> [::1]:5672
[error] <0.946.0> closing AMQP connection [::1]:49664 -> [::1]:5672 (duration: '2s'):
[error] <0.946.0> client did not start with AMQP protocol header: <<"hello\r\n\r">>
```

[Why]
Khepri already managed retries if needed, we can just use a timeout.

Note that the timeout was already bumped to a more appropriate 5
minutes, which also matches what we had with Mnesia. However, with 10
retries by default, it meant that this timeout at the end of `init/1`
would thus be 5 * 10 = 50 minutes.

This is a squashed commit that includes the following changes by @efimov90:

* Initial-theme-fix

Added light.css
Added dark.css
Added link for light.css and dark.css with media attribute
Added switcher

* Rework-light-style

* dark theme

* Removed not needed div

* Fix folder name

* Color scheme fix

Removes color-scheme from main.css
Added color-scheme: dark to dark.css
Added color-scheme: light to light.css

* Fixed theme switch bug with sammy.js

Adapts code to works with sammy.js

* Icons update

* Reworked theme switcher

* Fix updating attributes

---------

Authored-by: Sergey Efimov <efimov90@gmail.com>

…/1 and add amqqueue:make_internal/{1,2} type specs

This commit fixes a bug in the Erlang AMQP 1.0 client.

Prior to this commit, to repro this bug:
1. Send more than 2^16 messages to a queue.
2. Grant more than a total of 2^16 link credit initially (on a single link
   or across multiple links) on a single session without any
   auto or manual link credit renewal.

The expectation is that thanks to sufficiently granted initial link-credit,
the client will receive all messages.
However, consumption stops after exactly 2^16-1 messages.

That's because the client lib was never sending a flow frame to the server.
So, after the client received all 2^16-1 messages (the initial
incoming-window set by the client), the server's remote-incoming-window
reached 0 causing the server to stop delivering messages.

The expectation is that the client lib automatically handles session
flow control without any manual involvement of the client app.

This commit implements this fix:
* We keep the server's remote-incoming window always large by default as
  explained in https://www.rabbitmq.com/blog/2024/09/02/amqp-flow-control#incoming-window
* Hence, the client lib sets its incoming-window to 100,000 initially.
* The client lib tracks its incoming-window decrementing it by 1 for
  every transfer it received. (This wasn't done prior to this commit.)
* Whenever this window shrinks below 50,000, the client sends a flow
  frame without any link information widening its incoming-window back to 100,000.
* For test cases (maybe later for apps as well), there is a new function
  `amqp10_client_session:flow/3`, which allows for a test case to do manual
  session flow control. Its API is designed very similar to
  `amqp10_client_session:flow_link/4` in that the test can optionally request
  the lib to auto widen the session window whenever it falls below a certain threshold.

for the check introduced in #13487.

Note that encoding a regular expression pattern
with percent encoding is a pain (e.g. '.*' = '.%2a'),
so these endpoints fall back to a default pattern
value that matches all queues.

… endpoints