Avoid forking rootScopes for Reactor if current thread has NoOpScopes

[adinauer]

📜 Description

Avoid forking rootScopes for Reactor if current thread has NoOpScopes.

SentryReactorThreadLocalAccessor.getValue() invokes Sentry.getCurrentScopes() which will fork rootScopes if there is no instance of IScopes available (null or NoOpScopes).

We now check for existence of IScopes before invoking getCurrentScopes() in order to avoid the unnecessary overhead.

💡 Motivation and Context

Potential fix for #4762

💚 How did you test it?

📝 Checklist

• I added GH Issue ID & Linear ID
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• I updated the wizard if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.

🔮 Next steps

[github-actions]

	Fails
🚫	Please consider adding a changelog entry for the next release.

	Messages
📖	Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Instructions and example for changelog

Please add an entry to CHANGELOG.md to the "Unreleased" section. Make sure the entry includes this PR's number.

Example:

## Unreleased

- Avoid forking `rootScopes` for Reactor if current thread has NoOpScopes ([#4793](https://github.com/getsentry/sentry-java/pull/4793))

If none of the above apply, you can opt out of this check by adding #skip-changelog to the PR description or adding a skip-changelog label.

Generated by 🚫 dangerJS against 0914cbd

[adinauer]

An alternative to exposing this could be to have an overload of Sentry.getCurrentScopes() that could e.g. have a bool parameter to specify whether to fork rootScopes or just return NoOpScopes if there's nothing there yet.

[lcian]

Hmm yeah I would prefer this option, however for the purpose of the release I'm fine to go with this for now

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	414.75 ms	491.29 ms	76.54 ms
Size	1.58 MiB	2.11 MiB	539.21 KiB

Baseline results on branch: main

Startup times

Revision	Plain	With Sentry	Diff
806307f	357.85 ms	424.64 ms	66.79 ms
d217708	375.27 ms	415.68 ms	40.41 ms
ee747ae	374.71 ms	455.18 ms	80.47 ms
7314dbe	437.83 ms	505.64 ms	67.81 ms
3d205d0	352.15 ms	432.53 ms	80.38 ms
ee747ae	358.21 ms	389.41 ms	31.20 ms
d217708	355.34 ms	381.39 ms	26.05 ms
b3d8889	371.33 ms	426.24 ms	54.92 ms
d217708	409.83 ms	474.72 ms	64.89 ms
b750b96	421.25 ms	444.09 ms	22.84 ms

App size

Revision	Plain	With Sentry	Diff
806307f	1.58 MiB	2.10 MiB	533.42 KiB
d217708	1.58 MiB	2.10 MiB	532.97 KiB
ee747ae	1.58 MiB	2.10 MiB	530.95 KiB
7314dbe	1.58 MiB	2.10 MiB	533.45 KiB
3d205d0	1.58 MiB	2.10 MiB	532.97 KiB
ee747ae	1.58 MiB	2.10 MiB	530.95 KiB
d217708	1.58 MiB	2.10 MiB	532.97 KiB
b3d8889	1.58 MiB	2.10 MiB	535.07 KiB
d217708	1.58 MiB	2.10 MiB	532.97 KiB
b750b96	1.58 MiB	2.10 MiB	533.20 KiB

Previous results on branch: feat/reduce-scope-forking-for-reactor

Startup times

Revision	Plain	With Sentry	Diff
5e1cc3f	417.60 ms	485.16 ms	67.56 ms

App size

Revision	Plain	With Sentry	Diff
5e1cc3f	1.58 MiB	2.11 MiB	539.35 KiB

[lcian]

Hmm yeah I would prefer this option, however for the purpose of the release I'm fine to go with this for now