Consider using crypto/rand instead of math/rand

[liamsi]

Implementation ideas

In some places we use math/rand and plan to seed it differently (see #850) to achieve some non-determinism.

I think in all places which do not really touch a hot path, we should really be using crypto/rand even if they do not really have a hard requirement of cryptographically secure randomness. Otherwise, it remains unclear why math/rand was good enough or what the assumptions around the code were. Blindly using crypto/rand requires less bikeshedding on how to seed math/rand properly and it is clear that is the best we can do in terms of randomness. The performance penalty is negligible in the greater scheme of things (network + disk IO will always dominate here anyways).

[Wondertan]

The downside though is that crypto/rand does not provide convenience funcs like math/rand, e.g. shuffle, so crypto/rand usually requires some bikeshedding toward implementing the randomization logic, as it only provides basic rand data generation.

[saudch007]

Can I work on this one? @Wondertan