StrawberryIntegration mistakenly enables async extension

[sentrivana]

1. Rewrote my app's API from graphene-django to Strawberry (without touching my sentry_sdk.init( call which didn't have any integrations)
2. Tested thoroughly locally - API tests, Playwright tests, manually checked everything just to be sure
3. Deployed and watched everything break down with There is no current event loop in thread 'ThreadPoolExecutor-28_0'. exceptions on every request to my API

Turns out, Sentry somehow detected that I was using Strawberry, but didn't realize I was using GraphQLView and not AsyncGraphQLView. I'm assuming it started running async code, and that broke because it was doing it in a sync context.

I got really confused - even launching the production Docker image locally was completely fine. I just started adding the same build args, and it broke when I added SENTRY_DSN. Then, I found this issue in the Strawberry repo. Turns out, I'm not the first one.

Originally posted by @ipeterov in #4976

[linear]

PY-1911

[sentrivana]

Possible ways to go about this that I see at the moment:

1. We make the auto-detection smarter (right now it's very rudimentary).
2. We get rid of the auto-detection and always use the sync view unless the user opts in to the async one explicitly. Not ideal if someone is using async, but at least it won't blow everything up. Breaking for async users for whom the auto-detection works fine now.
3. We take Strawberry out of auto-enabling integrations. It's technically a breaking change, but it shouldn't have been made auto-enabling in the first place due to how brittle the auto-detection is.