Set the scope transaction for Otel transactions

[jamescrosswell]

Resolves #3061

Problem Summary

The SentrySpanProcessor wasn't setting the Scope.Transaction... so when using OpenTelemetry this was returning null:

sentry-dotnet/src/Sentry.DiagnosticSource/Internal/DiagnosticSource/SentrySqlListener.cs

Lines 75 to 79 in 84925a9

	var transaction = _hub.GetTransactionIfSampled();
	if (transaction == null)
	{
	return;
	}

Consequently the integrations weren't able to create DB Spans under the DB Root.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (b72b9e7) 76.42% compared to head (3a06c35) 76.45%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3072      +/-   ##
==========================================
+ Coverage   76.42%   76.45%   +0.03%     
==========================================
  Files         351      351              
  Lines       13263    13259       -4     
  Branches     2646     2644       -2     
==========================================
+ Hits        10136    10137       +1     
+ Misses       2450     2446       -4     
+ Partials      677      676       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[bitsandfoxes]

Why is this no longer needed?

[jamescrosswell]

I'm not sure if it was ever needed to be honest.

If the instrumenter is OpenTelemetry then we don't want our own Asp.NET Core integration also trying to instrument the same requests... so I can see why we might throw if an attempt is made to create a new transaction using the Sentry Hub.

I can't see any reason to prevent adding children to transactions that have already been created however.

I think this code was Matt's originally (I took it over part way through the PR)... so I'm not sure what his original reasoning was (I'm just guessing at it).

The alternative would be for calling methods in our own code to check what the current instrumenter is and pass that in as a parameter so as to sidestep the above check... that seemed like a weird solution. Those spans aren't actually coming from OpenTelemetry (they're coming from a Sentry integration). It seemed more honest just to admit that actually we're going to have Sentry child spans of OpenTelemetry transaction spans.