Use micrometer context-propagation to propagate auth between threadlocal and reactor ops

[ttddyy]

In spring mvc with reactive API, it uses a custom reactor subscriber, SecurityReactorContextSubscriber, to propagate the authentication and servlet request and response to the reactor operation chain. (Defined in SecurityReactorContextConfiguration imported by OAuth2ImportSelector)

The micrometer context-propagation library provides support for propagating such objects between threadlocal and reactor operation chains.

It is nice to migrate to it which aligns how micrometer observations are propagated as well as avoiding reactor corner cases that may not able to propagate by Hooks.onLastOperator.

cc @sjohnr, @chemicL

relates to #11973

[rstoyanchev]

Currently we have a SecurityContextThreadLocalAccessor in Spring for GraphQL that I can see would be more generally applicable. Not sure if that belongs in this issue or another.

[jzheaux]

@sjohnr, can you clarify here the difference between this ticket and #16665?

[chemicL]

@jzheaux Hey, I think I have some context here. I believe the change in #16665 adds optional support for the context-propagation in certain conditions:

to be used with blocking execution when automatic context propagation is enabled and the context-propagation library is on the classpath.

while this issue in particular is suggesting that the existing mechanism that uses onLastOperatorHook be replaced entirely. We discussed this with @sjohnr at one point and agreed that the security propagation can't rely on an optional dependency, hence context-propagation library would have to be required and the automatic propagation mode would need to be enabled. That is too much to ask from the users, but it can be helpful in certain scenarios that are already meeting these conditions.

If @ttddyy agrees and the optional support gives the users everything required, we could close this issue.

[ttddyy]

Yes, I agree — making it optional makes sense, and the necessary components are now in place.
With context propagation automatically enabled via the service loader, it provides a convenient experience for users.

To improve the developer experience further, it would be helpful to update existing consumers of these propagated objects.
For example, the current SecurityReactorContextSubscriber is used by ServletBearerExchangeFilterFunction and ServletOAuth2AuthorizedClientExchangeFilterFunction.

It would be great if they could auto-detect the presence of the new thread-local accessors and use them when available — particularly ServletBearerExchangeFilterFunction, since it only relies on Authentication.
Alternatively, introducing new implementations that support this pattern could be another approach.

If it's too much for now, it is probably nice to update the Javadoc to note that SecurityContext can now be retrieved from SecurityContextHolder when context propagation is enabled.