Named tracers with DiagnosticSources

[lmolkova]

Named tracers being introduces in #239 is intended to provide different behavior for different instrumentations (sampling, filtering, etc)

.NET/Microsoft provided libraries are typically instrumented with DiagnosticSource + Activity. DiagnosticSource already has filtering mechanisms that prevent any instrumentation from happening and performance-wise are better than named tracers.

We should define and implement how they would work together while keeping best performance we could get.

[lmolkova]

The approach I've been thinking about it:

• users enable listeners (i.e. OTel collectors per DiagnosticSource) by adding the reference to the collector library + configuring the listener.

• Listener SHOULD support configuration via tracer instance (named tracer instance) which could be set up by DI or configuration API helpers, It MAY provide configuration through TracerFactory and control category for the tracer.

• If users want to turn off certain listener they should prefer removing explicit configuration that turns it on rather than suppressing it via Factory/sampling/filter on Span processor

• If there is auto-instrumentation that brings certain listeners by default and could be changed in runtime, it MUST support config with the TracerFactory but MAY additionally support disabling certain listeners e.g. by package name (or any other name).

• If users want to provide custom configuration for certain listener, they could create Factory with a specific sampler, processors, exporter, etc... and pass tracer built from this factory to the collector.

Stay tuned for the PRs

[lmolkova]

this approach is implemented with #266 and #267