Refactor rand from ff to its own crate

[ValarDragon]

its a bit odd that test_rng and uniform_rand traits are coming from ark-ff at the moment. This also introduces oddities like #112 now introducing a dev-dependency to ark-serialize on ark-ff.

Refactoring this into its own crate I think will also give more flexibility for allowing feature flags on the test_rng that don't make sense to add when its on ark-ff. (E.g. making test_rng's seed non-static if you're trying to run randomized tests on more data points)

[Pratyush]

Yeah, I was thinking of moving them to ark-std. how does that sound?

[ValarDragon]

That sounds good to me

[ValarDragon]

Should rand be its own crate in arkworks-rs/utils, or should it just be a single file in ark-std?

[Pratyush]

just a single file in ark-std, probably a module named rand. (Basically, we would just move the rand module of ark-ff there)

[ValarDragon]

Opened a PR to do that on ark-std. I think we should then mark the rand methods in ark-ff as deprecated (so that things won't break in release v0.2.0), and then delete the methods in ark-ff on master after the next release.

[Pratyush]

Let's re-export ark-std's rand to avoid this breakage; you can mark it as deprecated by annotating it with the #[deprecated] attribute.

[ValarDragon]

We can't deprecate a re-export unfortunately (rust-lang/rust#30827)

I propose for now we do the following:

• have ark-ff re-export the UniformRand trait with a notice in the changelog that its deprecated and to update your dependency before the next release. This is because UniformRand is a trait, and multiple versions will probably cause issues AFAIU.

• Have ark-ff re-implement test_rng(), with a deprecated flag to switch to ark_std. (Which will also remind them to switch for Uniform Rand if they use it)

[Pratyush]

Hmm that's unfortunate, but your workaround is good enough, I suppose.