perf: random tokens do not need to be hashed

[dhensby]

There are some wasted CPU cycles when generating the random tokens.

There's no need to generate extra random bytes only to hash them. A random input will lead to a random hash being generated, but the random input is enough in its own right and does not need to be hashed to make it any more or less secure. The amount of entropy is capped at 32 bytes when hashed, so we may as well just provide 32 random bytes.

As an added bonus, this also returns the method to a true non-blocking async function.

[jankapunkt]

@dhensby thanks for the improvement. Do you have experience with performance tests? I think they would be a great addition in the long run for methods like these.

[dhensby]

I haven't written or run performance tests before. I know there are even more theoretical improvements to be made to performance around random number generation (I know that the uuid lib has done some performance work around that by not hitting randomBytes every time), but it depend how focused on performance we are whether we want to implement those kinds of optimisations.