Add ActivitySource to SamplingParameters

[FstTesla]

The SamplingParameters struct almost mirrors the ActivityCreationOptions struct. Anyway, it has no reference to the ActivitySource that wants to create a new Activity, unlike the ActivityCreationOptions.Source property.
The absence of such property in the SamplingParameters prevents a sampler from making a decision based on criteria that include the activity source; in other words, activities are indistinguishable source-wise from the point of view of the sampler.

Please note that sampling at Sampler level is not the same as including or not an activity source with the TracerProviderBuilder.AddSource method. This is also because the AddSource method accepts wildcards, which means that all matching activity sources will be included, with no way of removing specific ones. This can be useful when the list of desired activity sources is dynamic or initially unknown.

At the moment, the only alternative to this is registering a filtering processor (a subclass of BaseProcessor<Activity>) that un-flags the Activity as recorded, therefore making it unavailable for export.
Anyway this approach has at least two major disadvantages:

• Creating a non-recorded Activity is not the same as not creating it at all, since other processors / ActivityListeners can still see it and cause side effects despite its trace flags.
• Even admitting that all registered ActivityListeners are "fair" (they do nothing if an Activity is non-recorded), the filtering processor must be the first one to be executed; anyway, this cannot be taken as granted and there is no public way to reorder the processors.

My suggestion is to add an ActivitySource Source property to the SamplingParameters struct, that can be populated from the corresponding property in the ActivityCreationOptions struct.

[vishweshbankwar]

SamplingParameters follows the specification which does not contain ActivitySource/Scope information. https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/sdk.md#:~:text=to%20be%20created.-,Required%20arguments%3A,-Context%20with%20parent

Related: #4371

[cijothomas]

open-telemetry/opentelemetry-specification#1942 More history. I was added, but then reverted.

[martinjt]

There's a fine line implementing what the spec says, and what the SDK says is needed. I'm sure there are places in our SDK that we go beyond what the spec says as a minimum.

I don't see anywhere in the spec that say we "can't" or "Shouldn't" do it though.

That is to say, it's a choice that we're not going to pass it in within the .NET implementation. If we're not going to do this, I think we should close of this issue and give some closure for @FstTesla so they're not waiting on it.

[cijothomas]

I don't see anywhere in the spec that say we "can't" or "Shouldn't" do it though.

Yes. Remember that scopes were added to samplinginput to the spec, but then reverted, and there are plenty of open spec issues, like open-telemetry/opentelemetry-specification#3867
We need to wait for spec resolution before making a new addition.

@FstTesla We are not adding it to OTel .NET, unless the spec is changed to allow that. It is possible that spec might be solving this problem in a different way. Please follow the spec issue for updates.