Split out ReactorUtils and required classes from Spring integration

[Angelodaniel]

Problem Statement

We already have support for reactor in our Spring integration as part of the WebFlux specifics. Users who are not using Spring would also like to use e.g. ReactorUtils so they don't have to deal with Hub propagation themselves.

Solution Brainstorm

• Create a new gradle module and publish as a separate dependency with minimum dependencies (e.g. don't drag in Spring)
• Move classes over there and make the Spring module depend on it
  • https://github.com/getsentry/sentry-java/blob/7c33bc1f1ab8a05431bab8cc595d14cde070[…]rc/main/java/io/sentry/spring/jakarta/webflux/ReactorUtils.java
  • https://github.com/getsentry/sentry-java/blob/main/sentry-spring-jakarta/src/main/java/io/sentry/spring/jakarta/webflux/SentryReactorThreadLocalAccessor.java
  • Tests
  • there may be more classes required

To consider:

Do we want to always bring this new module as a dependency for Spring or do we want to rely on our build plugins to automatically add it and code it in a way where it has to be added manually as a dependency by the user when not using our build plugin auto install feature?

Probably not worth it to make it an optional dependency if it doesn't have any dependencies of its own as it just creates a pitfall.

┆Issue is synchronized with this Jira Improvement by Unito

[Angelodaniel]

Customer mitigated the problem by copying the functionality. So I would say this is low prio @adinauer

[kahest]

Thanks for the update/workaround @Angelodaniel

[adinauer]

Thanks @Angelodaniel I've reduce prio a bit but still think we should do this as it's not a lot of work and can help some users running into the same problem.

[lcian]

Closing this as the feature has been merged in #4155
Post-release tasks are being tracked here #4199