WIP: op_get_random_values

[chiefbiiko]

First shot at #2321

The CSPRNG in use is Rust's rand::rngs::ThreadRng.

Exposed as globalThis.crypto.getRandomValues().

Following Crypto.getRandomValues(), but not completely.

Overlaps:

• function signature (passing an integer-based TypedArray)

Differences:

• errors
  • not throwing a QuotaExceedError if the input length is gt 65536
    • now throwing an AssertionError for this case
  • passing null as input does not raise an exception until reaching Rustland
• sync and async variations
• additional support for BigInt64Array and BigUint64Array

Since these differences are incompatible with the browers' Crypto interface I just polluted Deno... 4give

[CLAassistant]

All committers have signed the CLA.

[zekth]

i personnaly think Crypto.getRandomValues has to be similar as the browser implementation. So maybe add Crypto.getRandomValuesAsync() ?

Just a question : https://github.com/denoland/deno/pull/2327/files#diff-78d0badf3715ce7e0e4ddd06cb279f35

How you ensure the result of getRandomValues is the sametype as the input typed array? You don't check the input type on the rust side. I was stuck on this part on my side.
You check with assertNotEquals but you don't check the type of the entries of the array or even the type of the output array. By using the abstraction ArrayBufferView the typearray type may change no?

[zekth]

this is not necessary IMO.

[chiefbiiko]

My rustc demands it.

[ry]

Currently CI is failing due to formatting. If you look at the end of the logs you'll see this:

Run tools/format.py 
 M cli/ops.rs

Also be sure to run "tools/lint.py"

[ry]

LGTM - nice addition