Refactor Random module

[e-kayrakli]

This PR refactors the Random module as documented in several notes.
Specifically:

• RandomStream class is renamed to PCGRandomStream.
• RandomStream is now a type alias for the default random stream.
• defaultRNG is now a config param instead of just param.
• makeRandomStream is now deprecated.
• Both NPBRandomStream and PCGRandomStream now have create type methods.
• private proc chpl_createStream can be used to create a random stream similar
  to now-deprecated makeRandomStream

As a result, several modules and tests are modified to use the new factory
function.

Test:

• standard
• gasnet

[e-kayrakli]

This started as part of resolving #14291. However, the Random module needed some more work to change the factory function, so I separated this from that branch. There'll be another PR for resolving #14291 more fully.

Update: Main factory functions PR is #14449

[mppf]

I'm on board with renaming RandomStream to PCGRandomStream.

I'm unconvinced that we need to deprecate makeRandomStream.

[mppf]

It's not obvious to me why we need to deprecate makeRandomStream. It's doing something slightly different, isn't it? The param algorithm pattern exists also for a bunch of other functions here, so it seems to me like we should keep it.

[e-kayrakli]

My main motivation was because it was one of the factory functions that are listed in #14291.

I understand your point that this is not a typical function, but at the same time I think it should follow the "convention" we are trying to set somehow, so maybe it should be just renamed to createRandomStream and we should ditch the idea of having RandomStream.create because it is not much different than new owned RandomStream as you point out below?

[mppf]

It seems to me, if we want to update for #14291, we should just rename the function to createRandomStream.

[ben-albrecht]

Only loosely following the discussion and PR(s), but it didn't seem like #14291 had reached a consensus on when to use type.create() vs. createType() from what I can tell.

so maybe it should be just renamed to createRandomStream and we should ditch the idea of having RandomStream.create because it is not much different than new owned RandomStream as you point out below?

If this is the case, maybe we should consider removing createRandomStream and have users call new. Does the factory function save much effort compared to new owned RandomStream?

[mppf]

It allows one to easily parameterize the RNG used (with the algorithm argument)

[ben-albrecht]

OK, and just so I understand, does this represent the interfaces being considered?

RandomStream.create(algorithm=PCG);
// same as
PCGRandomStream.create();
// same as 
new owned PCGRandomStream();

//
// vs.
//

createRandomStream(algorithm=PCG);
// same as
new owned PCGRandomStream();

[mppf]

I think we decided not to make PCGRandomStream.create();.

[e-kayrakli]

@ben-albrecht We currently have the second version of those, but the alternative was slightly different than your 1st version. It is more like

RandomStream.create();
// same as (if defaultRNG==RNG.PCG, which is the default)
PCGRandomStream.create();
// same as
new owned PCGRandomStream();

My point being RandomStream is only a type alias to the default type, and not a type itself.

[mppf]

If we keep this change, the documentation & method should also appear in RandomStreamInterface

[mppf]

I don't understand why we need type create when a regular new will do.

Isn't NPBRandomStream.create(int, seed) redundant with new owned NPBRandomStream(int, seed) ?

[e-kayrakli]

I didn't want to rebase this branch and lose this history (just in case) to address the feedback. I am closing this PR. #14452 supersedes this.