CP-49135: speed up UUID generation

[edwintorok]

2 optimizations here:

• open /dev/urandom just once, speeds up session uuid/ref creation by ~3.8x
• use a PRNG for non-secret UUIDs. We cannot use these for sessions (those UUIDs/opaquerefs are effectively the authentication tokens), or Pool secrets, but we can use it for everything else.

The latter is not yet enabled by default, needs more testing/auditing on whether we have any other secret opaquerefs/UUIDs in the codebase, but the 1st one is enabled by default (we still use /dev/urandom for generating the UUIDs, we just don't keep closing and reopening it).

[edwintorok]

Back to draft, this seems to reveal a bug somewhere else in the codebase (someone closed the wrong file descriptor and ended up closing the urandom one...)

[edwintorok]

Back to draft, this seems to reveal a bug somewhere else in the codebase (someone closed the wrong file descriptor and ended up closing the urandom one...)

Ah crowbar runs at_exit so I can't use at_exit to close this, because that'll then run before the Crowbar tests, making them all fail (fixed).

And forkexecd isn't happy about the extra FD either (fixed).

TODO: split up the last commit that adds type safety for session into its own commit.

[psafont]

Thanks, It's interesting to clearly see the types weren't used properly before, and now they are being tracked as they should

[edwintorok]

I've split the type safety changes into their own commits, and also introduced a 'Ref.of_secret_string' to more clearly separate the two.

Of course the type system can't tell us if we use secret UUIDs anywhere other than Session, it is up to us to tell it the list of classes that have secret uuids. Also if you immediately convert a Uuidx.t to a string you wouldn't get an error that you generated it wrongly (but usually Ref and UUID generation are close together, as in the session code).