Sentry recovers after a Thread had currentHub set to a NoOpHub

[adinauer]

📜 Description

When a call to Sentry happens before Sentry.init, the currentHub is set to a NoOpHub. If Sentry.init is then called in a different thread, the thread where Sentry was called before init is poisoned without this change. By checking if the currentHub is a NoOpHub we can allow the poisoned thread to self heal.

💡 Motivation and Context

Happened to a customer who set up a thread pool and had executions happen before being able to initialize Sentry.

💚 How did you test it?

Unit Test

📝 Checklist

• I reviewed the submitted code
• I added tests to verify the changes
• I updated the docs if needed
• No breaking changes

🔮 Next steps

Discuss if this has any consequences I can't see.

[nickrobison]

Thanks folks! This is going to be a huge help for us!

[github-actions]

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

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

- Sentry recovers after a Thread had currentHub set to a NoOpHub ([#2076](https://github.com/getsentry/sentry-java/pull/2076))

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

Generated by 🚫 dangerJS against 76227dd