Sampling based `Transaction.NoOp` to easy memory pressure

[bitsandfoxes]

What

Came up in #3581 (comment)
It does not matter whether a transaction gets sampled or not, they still require the same amount of resources - i.e. memory.

How

We could expand on this on the NoOp. Instead of a NoOpTransaction singleton we could pass around something like a SampledTransaction that are functionally NoOp but hold the data required to provide a client report - i.e. span count. I guess the same could work for spans? That way we'd get rid of all the data we know will get discarded in the end anyway.

Context

We introduced the NoOp transaction with the SDK disabled here: https://github.com/getsentry/sentry-dotnet/pull/3581/files and we could expand on this.

When starting a transaction it either has its sampling decision already set or it goes through the TracesSampler (if provided)

sentry-dotnet/src/Sentry/Internal/Hub.cs

Lines 149 to 153 in 12c7d7c

	if (tracesSampler(samplingContext) is { } sampleRate)
	{
	transaction.IsSampled = _randomValuesFactory.NextBool(sampleRate);
	transaction.SampleRate = sampleRate;
	}

or it gets it's sampling state set randomly

sentry-dotnet/src/Sentry/Internal/Hub.cs

Line 162 in 12c7d7c

transaction.IsSampled = _randomValuesFactory.NextBool(sampleRate);

So we know right from the beginning if a transaction ends up in a client report or not.

[Joshhua5]

Thanks for creating this, we've had to slow down our Sentry adoption on some high throughput API's due to the overhead causing OOM in Kubernetes, reducing the sampling rate wasn't effective at curbing the overhead of adding sentry. Which this ticket targets directly