[sdk] Only use BCL HashCode for .NET 6+

[CodeBlanch]

Relates to #4204

Changes

• Updates preprocessor directives around System.HashCode so it is only used on .NET6+ runtimes.

Details

We were talking about metrics not working on .NET Core 3.1 (#4204) today on the SIG. The issue seems to be differences around null handling in HashCode, which is very strange. I did some digging on it.

• .NET Core 3.1: https://github.com/dotnet/corefx/blob/34a90650962f0a911b471584b5eeb9ba7de5581e/src/Common/src/CoreLib/System/HashCode.cs#L304-L307
• .NET current: https://github.com/dotnet/runtime/blob/c36e26d1f6d11c657e8083ecbcbe831b29afa27a/src/libraries/System.Private.CoreLib/src/System/HashCode.cs#L307-L310

It seems like this PR accidentally introduced a breaking logical change in HashCode.

What this means is .NET Standard 2.1 and .NET6+ versions of HashCode have logical differences. To be safe and avoid any issues I thought it best just to use our fallback logic for .NET Standard 2.1.

PS: There is an out-of-band NuGet version of HashCode. I tried all versions of it, none of them have the null logic updated to match dotnet/runtime current state.

Merge requirement checklist

• CONTRIBUTING guidelines followed (nullable enabled, static analysis, etc.)
• Appropriate CHANGELOG.md files updated for non-trivial changes

[reyang]

It seems like this PR accidentally introduced a breaking logical change in HashCode.

Is this considered as a breaking change or not (from .NET team's perspective)?

[codecov]

Codecov Report

Merging #4362 (feac846) into main (78abc68) will increase coverage by 0.01%.
The diff coverage is n/a.

❗ Current head feac846 differs from pull request most recent head c346cbc. Consider uploading reports for the commit c346cbc to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4362      +/-   ##
==========================================
+ Coverage   84.79%   84.81%   +0.01%     
==========================================
  Files         300      300              
  Lines       12065    12065              
==========================================
+ Hits        10231    10233       +2     
+ Misses       1834     1832       -2     

Impacted Files	Coverage Δ
src/OpenTelemetry/Metrics/MetricStreamIdentity.cs	93.18% <ø> (ø)
...enTelemetry/Metrics/StringArrayEqualityComparer.cs	84.21% <ø> (ø)
src/OpenTelemetry/Metrics/Tags.cs	86.66% <ø> (ø)
src/OpenTelemetry/Trace/SamplingResult.cs	100.00% <ø> (ø)

... and 3 files with indirect coverage changes

[CodeBlanch]

Is this considered as a breaking change or not (from .NET team's perspective)?

The PR title is "Help compiler enforce nullability annotations" not anything about changing HashCode so I suspect it was accidental. Whether or not they will own it as "breaking" who knows 🤷 I don't think the classification really matters as far as this fix is concerned though?

[alanwest]

This PR has me wondering if it would just make sense to remove all NETSTANDARD2_1 preprocessor directives.

I think in some situations this will mean that certain perf improvements will not be available to netstandard2.1 builds, but I think that's ok.

I don't think I feel the same way about NETSTANDARD2_0 directives because netstandard2.0 serves folks sharing code between .NET Framework and modern .NET.