Fixing HashCode Seed Initialization on BCL package

[joperezr]

fixes dotnet/runtime#42808

Fixing seed initialization on Microsoft.Bcl.Hashcode to match netcoreapp behavior. Also provided a quirk in case people consuming the BCL package want to fall back to the non-randomized version.

cc: @stephentoub @bartonjs @ericstj @fabricefou @Anipik

Customer Impact

NetStandard implementation of GetRandomBytes has a bug which causes it to always return 0. This is used by HashCode when generating its internal seed used for generating hashes, which causes the user to get non-random hashes when consuming the Microsoft.Bcl.HashCode package in netstandard.

Testing

We added test coverage as part of this PR to ensure that a) Customers behavior will now be the same in netcoreapp and netfx and b) we added an AppContext switch so that folks can fall back to wrong behavior if they depended on non-randomized hashes.

Regression?

No. This package has had the incorrect behavior since we initially shipped it.

Risk

Low. It may break customers that depended on the wrong behavior, but for such cases we provided an AppContext switch that they can decide to turn on if necessary.

[ericstj]

Can you add a test case for this? Maybe remote executor could help you test hashing same data from two different AppDomains to ensure you get a different result.

[bartonjs]

I don't know of a very good way of testing it (maybe: calculate a hash locally and use the remote process launcher to calculate the same hash, and make sure they're different?).

Alternatively, reflection to ensure the seed isn't zero? (should be a low enough failure rate at about 1 in 4 billion)

LGTM provided at least local verification has happened since the last edit.

[ericstj]

calculate a hash locally and use the remote process launcher to calculate the same hash, and make sure they're different?

This was my thought, or call it twice in remote process and make sure we get different results.

[joperezr]

cc @aik-jahoda as you are handling servicing for 3.1

[joperezr]

Merging since the failing CI are due to tests in System.Text.RegularExpressions. cc: @pgovind since I've seen these failures on pretty much every iteration of my PR so we should investigate or disable.

[ericstj]

I believe those failing tests are tracked with dotnet/runtime#41286.

[pgovind]

we should investigate or disable.

I'm not sure we even know which test is failing. When we looked at the logs the last time, I just saw "Tests failed, no dump available" (paraphrasing). If we can find the failing tests, I don't mind disabling them!

[ericstj]

I added some details to the issue. At least one of the failures in this PR pointed to a single long running tests. The others were all a SIGKILL.