feat: add true randomness

[immortal-tofu]

Simple PR to review.

• I'm wondering if I can do better to transform upperBound to a number of bits.
• Not sure about the used seed.

[jatZama]

Previously fheRand and fheRandBounded did not support uint4 so I excluded the type 1 from supported types in Coprocessor contract : https://github.com/zama-ai/coprocessor-contracts/blob/main/contracts/FHEVMCoprocessor.sol#L393-L402
Did this change it seems?
Also I noticed you changed upperBound to numberOfBits, does this mean that I should drop the isPowerOfTwo function in coprocessor contract? https://github.com/zama-ai/coprocessor-contracts/blob/main/contracts/FHEVMCoprocessor.sol#L73
Another issue is that this would mean @david-zk would also need to refactor fhevm-go-coprocessor. I was not aware this feature was needed for current release in one week.

[immortal-tofu]

We decided to display a upper bound instead of a number of bits in the Solidity API, so nothing change from a developer perspective. cc @mortendahl
We can add rand and randBounded for euint4, but in Q3. What I have added is not in Coprocessor yet, and maybe won't be in coprocessor in Q2. cc @david-zk

[dartdart26]

AFAIU, the seed can just be a counter. Right now, we hash a fixed global seed and the caller address, leading to the same seed every time. We should double check with tfhe-rs and, if that's the case, change the seed.

[immortal-tofu]

OK you mean we could use directly globalRngSeed ?

[mortendahl]

Is globalRngSeed incremented after each use?

[immortal-tofu]

Maybe nextRngNonce is a better choice. I don't see where we use it right now

[mortendahl]

I am getting it right, that globalRngSeed/nextRngNonce is local state? For the coprocessor we might want to avoid this, and instead use a counter from Solidity. This would make the coprocessor computation stateless and reproducible. To generate the symbolic values for random encryptions, we need a Solidity counter (plaintext integer) anyways. This counter could be used here as well.