[Traces] Support named options in HttpClient instrumentation

[CodeBlanch]

Resolves #3434

Changes

• Removes netstandard2.0 target and adds net6.0.
• Applies the named options pattern from [Metrics] Clean up repo exporters to use new DI patterns #3648 to HttpClient tracer builder extension.

TODOs

• Appropriate CHANGELOG.md updated for non-trivial changes
• Unit tests
• Changes in public API reviewed

[CodeBlanch]

@alanwest @utpilla @cijothomas Hey I dropped netstandard2.0 and added net6.0. The netstandard2.0 didn't really make sense to me. We've seen users reference this in netstandard2.0 projects which then blow up when consumed into net462 projects because the API is different. Seems like this is a safer way to go about things?

[alanwest]

This would resolve #3434. Technically, this is sort of a breaking change.

I suspect that the use of the HttpClient instrumentation is pretty ubiquitous. Given that this change will require .NET Framework users who have shared netstandard libraries to retarget their libraries, I think we may as well rip the bandaid off and remove netstandard targets from all our packages.

[cijothomas]

agree with this change to HttpClientInstrumenttion.
Those consuming this via shared library will see breakage, unless the shared library also updates their target.
Those consuming this directly from app (like a Asp.Net or Asp.Net core) app should see no breakage.

Changing ns20 target from API/SDK packages should be discussed separately, as those are stable packages, unlike httpclient instrumentation.

[CodeBlanch]

I merged this. Felt like it was good to get it in, get it out there, see if we get any feedback.

This change would have also worked:

<TargetFrameworks>netstandard2.1;net462</TargetFrameworks>

Because .NET Framework does not implement .NET Standard 2.1, users would get the correct version in that case.

Not sure which is the best way to go.

• We don't have netstandard2.1 in AspNetCore instrumentation currently.
• We do have netstandard2.0 in API+SDK and netstandard2.1 in SDK.

If our goal is to drop support for <net6.0 we should maybe just go to <TargetFrameworks>net6.0;net462</TargetFrameworks> across the board. It will be bumpy, but clear. Otherwise perhaps we should keep netstandard2.1 in HttpClient + AspNetCore.

[codecov]

Codecov Report

Merging #3664 (c1ed5f3) into main (960908c) will increase coverage by 0.08%.
The diff coverage is 100.00%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3664      +/-   ##
==========================================
+ Coverage   87.54%   87.62%   +0.08%     
==========================================
  Files         283      283              
  Lines       10283    10286       +3     
==========================================
+ Hits         9002     9013      +11     
+ Misses       1281     1273       -8     

Impacted Files	Coverage Δ
...umentation.Http/TracerProviderBuilderExtensions.cs	100.00% <100.00%> (ø)
src/OpenTelemetry/Logs/Pool/LogRecordSharedPool.cs	78.94% <0.00%> (-18.43%)	⬇️
...emetry.Api/Internal/OpenTelemetryApiEventSource.cs	76.47% <0.00%> (-5.89%)	⬇️
...Telemetry/Internal/SelfDiagnosticsEventListener.cs	97.65% <0.00%> (+0.78%)	⬆️
....Prometheus.HttpListener/PrometheusHttpListener.cs	80.00% <0.00%> (+1.33%)	⬆️
...metryProtocol/Implementation/ActivityExtensions.cs	95.05% <0.00%> (+3.29%)	⬆️
...ZPages/Implementation/ZPagesExporterEventSource.cs	62.50% <0.00%> (+6.25%)	⬆️
...xporter.OpenTelemetryProtocol/OtlpTraceExporter.cs	77.27% <0.00%> (+18.18%)	⬆️
...entation/ExportClient/OtlpGrpcTraceExportClient.cs	78.57% <0.00%> (+28.57%)	⬆️