• Closes: #43424

We always add `SecurityContextOverrideHandler` https://github.com/quarkusio/quarkus/blob/78ff38019b9c9632ed64ade2ce3e20ccc4a2c163/extensions/resteasy-reactive/rest/deployment/src/main/java/io/quarkus/resteasy/reactive/server/deployment/ResteasyReactiveProcessor.java#L1344.

But we only add security integration when the Quarkus Security extension is present https://github.com/quarkusio/quarkus/blob/78ff38019b9c9632ed64ade2ce3e20ccc4a2c163/extensions/resteasy-reactive/rest/deployment/src/main/java/io/quarkus/resteasy/reactive/server/deployment/ResteasyReactiveProcessor.java#L1587.

It won't cause any NPE when user doesn't do any security, because we only request `SecurityIdentityAssociation` when user implemented custom JAX-RS security context. However if user does implement custom JAX-RS security context and no Quarkus Security is present, NPE could happen that is fixed by this PR.

What is the point of keeping `SecurityContextOverrideHandler` without Quarkus Security? IMO it's extremely edge case, but I have seen before one reproducer where user did all the security himself and relied strictly on JAX-RS concepts. No point stopping them. I have decided to keep this handler because `CurrentIdentityAssociation` is a separate API from the Quarkus Security and it is always possible that some users decided to provide it themselves, so I don't want to break things.

Ad testing - this could only be tested without Quarkus Security in the test scope, so I only tried it locally.