Use getrandom in uniqid() and mt_rand() / mt_srand().

[zeriyoshi]

Proposal to Internals: https://externals.io/message/112525

For these functions, use the more secure random source provided by the operating system if available.
A slight performance degradation is expected (Especially Linux, kernel's uses spinlock.), but the impact is minor and only at first time.

Also, no changes has provided for GENERATE_SEED() in gmp. This is because I am not familiar with this extension.

[TysonAndre]

At a glance, I don't have any objections

• Anything that needed deterministic random bytes would already be calling mt_srand() with a provided seed (before using random algorithms) and would be unaffected by this change
• /dev/urandom shouldn't/doesn't block on unix (not familiar with Windows)
• The OS's secure random number generator should be an improvement over the existing pseudo-random implementation if this PR is properly checking that enough bytes are fetched.

[nikic]

I find the double division here rather odd, why not ((double) bytes / UINT32_MAX) * 10.0?

It would be good if you could check how much this impacts performance of uniqid. I'm not really concerned about the seeding for mt_rand as it happens once, but this happens on every call to uniqid.

[zeriyoshi]

Fixed it. I'm so ashamed.

Trying to benchmarking uniqid(), There was no noticeable performance degradation, even in the most unlikely use cases. (In Debian Buster on Docker for Mac)

# original
$ time ./sapi/cli/php -r 'foreach (range(1, 100000) as $i) { uniqid(); }'

real    0m0.674s
user    0m0.071s
sys     0m0.595s

# use php_random_bytes()
$ time ./sapi/cli/php -r 'foreach (range(1, 100000) as $i) { uniqid(); }'

real    0m0.656s
user    0m0.073s
sys     0m0.572s

[nikic]

The case you are testing does not have more_entropy set, so it does not actually test this code path. However, from my own test the new code is just 35% slower (Ubuntu), so I think this change is not problematic.