Fix priority of interceptors preventing repeated security checks so that interceptor activating CDI request context runs first

[michalvavrik]

Makes sure that ActivateRequestContextInterceptor runs before interceptors that prevent repeated checks which already happened eagerly.

Motivation for this change: quarkiverse/quarkus-langchain4j#539 (comment)

When HTTP request has completed, the interceptors preventing repeated checks must applied without internal error. See linked issue for more information.

New order:

• ActivateRequestContextInterceptor priority 100 (activate request context)
• StandardSecurityCheckInterceptors priority 900 (prevent repeated checks if the security check had been performed eagerly)
• standard security interceptors 1000 (secure CDI beans and play fallback security role for the resources)

It is fairly edge case because it's hard to avoid active CDI request context at that point and if you activate it, you don't have the identity unless you do custom security yourself. Still, it's right thing to fix it.

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit 94ed0d3.

Failing Jobs

Status	Name	Step	Failures	Logs	Raw logs	Build scan
✖	MicroProfile TCKs Tests	Verify	Failures	Logs	Raw logs	🔍

Full information is available in the Build summary check run.
You can consult the Develocity build scans.

Failures

⚙️ MicroProfile TCKs Tests #

- Failing: tcks/microprofile-opentelemetry 

📦 tcks/microprofile-opentelemetry

✖ org.eclipse.microprofile.telemetry.tracing.tck.async.MpRestClientAsyncTest.testIntegrationWithMpRestClient - History - More details - Source on GitHub

java.util.concurrent.RejectedExecutionException: event executor terminated
	at io.netty.util.concurrent.SingleThreadEventExecutor.reject(SingleThreadEventExecutor.java:934)
	at io.netty.util.concurrent.SingleThreadEventExecutor.offerTask(SingleThreadEventExecutor.java:351)
	at io.netty.util.concurrent.SingleThreadEventExecutor.addTask(SingleThreadEventExecutor.java:344)
	at io.netty.util.concurrent.SingleThreadEventExecutor.execute(SingleThreadEventExecutor.java:836)
	at io.netty.util.concurrent.SingleThreadEventExecutor.execute0(SingleThreadEventExecutor.java:827)
	at io.netty.util.concurrent.SingleThreadEventExecutor.execute(SingleThreadEventExecutor.java:817)
	at io.vertx.core.impl.EventLoopExecutor.execute(EventLoopExecutor.java:35)

---

Flaky tests - Develocity

⚙️ JVM Tests - JDK 17

📦 integration-tests/reactive-messaging-kafka

✖ io.quarkus.it.kafka.KafkaConnectorTest.testFruits - History

• Assertion condition defined as a Lambda expression in io.quarkus.it.kafka.KafkaConnectorTest expected: <6> but was: <5> within 10 seconds. - org.awaitility.core.ConditionTimeoutException

org.awaitility.core.ConditionTimeoutException: Assertion condition defined as a Lambda expression in io.quarkus.it.kafka.KafkaConnectorTest expected: <6> but was: <5> within 10 seconds.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
	at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
	at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:1006)
	at org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:790)
	at io.quarkus.it.kafka.KafkaConnectorTest.testFruits(KafkaConnectorTest.java:63)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)

[sberyozkin]

Thanks @michalvavrik, I also opened the discussion at #40798. Like you say this change won't make the identity available due ActiveRequestContext methods if the context was already terminated, but at least we can now avoid a confusing error from the standard security check interceptor