Match the behavior of SystemRandomSource to System.Random

[hikarin522]

In .NET 6, new System.Random() with no arguments is changed to xoshiro256**.
dotnet/runtime#47085

[cdrnet]

Related: doesn't .NET 6 also introduce a shared Random instance? Maybe that could be useful for us also.

[cdrnet]

Note, the reason we pass in a seed is to avoid the problem Random used to have when you create multiple instances very quickly they are not guaranteed to be independent (they could end up with the same seed). Is this also resolved then in .NET 6?

[hikarin522]

Related: doesn't .NET 6 also introduce a shared Random instance?

When #885 is merged, I will issue the following commit pull request.

hikarin522@f132aa5

[hikarin522]

Note, the reason we pass in a seed is to avoid the problem Random used to have when you create multiple instances very quickly they are not guaranteed to be independent (they could end up with the same seed). Is this also resolved then in .NET 6?

https://docs.microsoft.com/dotnet/api/system.random.-ctor#System_Random__ctor

In .NET Framework, the default seed value is derived from the system clock, which has finite resolution. As a result, different Random objects that are created in close succession by a call to the parameterless constructor have identical default seed values and, therefore, produce identical sets of random numbers. You can avoid this problem by using a single Random object to generate all random numbers. You can also work around it by generating your own random seed value and passing it to the Random(Int32) constructor. For more information, see the Random(Int32) constructor.
In .NET Core, the default seed value is produced by the thread-static, pseudo-random number generator, so the previously described limitation does not apply. Different Random objects created in close succession produce different sets of random numbers in .NET Core.

The .NET Framework causes problems so I'll fix it.

[hikarin522]

Fixed.

[cdrnet]

I have not merged yet because I first would like to bring out v5 which mainly changes a few things around native providers and how they are isolated, loaded an packaged (and make them work again for Linux if possible). As soon as this is out, we can finally start to move towards .NET 5 and 6. Sorry for this delay.