CP-34028: implement Uuid with Uuidm

[psafont]

The Uuid module is problematic because it doesn't parse input at all. This PR tries to do a better job at that and replaces its base type from string to Uuidm, which should makes the representation more compact when used at the expense of conversion roundtrips when reading the database

In order to guard from invalid values it's necessary to change the interface to use Option: using exceptions would be dangerous and some uses might be missed and lead to unhandled exceptions.

Draft PR as it has a breaking change so clients need to be modified first; I would like some feedback before doing that.

TODO: The functions that generate random UUID do not use the ones provided by Uuidm. I don't think the Option.get is worrying because previously a different exception would have been raised, but there's a chance to make it more robust.

Notes:

• While having the phantom type makes sense to avoid comparing uuid of different types of resources, xapi needs to have a dedicated type to model uuids instead of using strings.

• On top of this, using Uuid.t means that for every roundtrip we're paying the cost of converting from the string representation to the raw byte value and viceversa which may impact performance, having the string representation with the new interface may be more desirable.

Original PR can be found in xapi-project/xen-api-libs-transitional#103

[lindig]

We have two functions to create a UUID. It's not obvious when to use which.

[psafont]

I'll remove the make_uuid_urnd and document the random source for make.

[lindig]

I think this is a good change but it touches a lot of code. Random thoughts:

• The old code supported UUIDs of different length and we always use the V4 variant. I assume we don't need the flexibility to change this and Uuid as a module does not need to be as general.

• Most use cases need a UUID in string representation. This could be supported directly with a make_string or similar function to avoid Uuid.to_string (Uuid.make ()) everywhere.

• Given that we mostly use strings, where is the compact representation used?

[psafont]

The old code supported UUIDs of different length and we always use the V4 variant. I assume we don't need the flexibility to change this and Uuid as a module does not need to be as general.

This is the first time I hear UUIDs can have variable length, RFC 4122 is clear on this:

The UUID format is 16 octets; some bits of the eight octet variant field specified below determine finer structure.

Is there a non-standard source of UUIDs that we have to support? I'll test the changes before undrafting anyway to try to discover any unpleasant surprises

Most use cases need a UUID in string representation. This could be supported directly with a make_string or similar function to avoid Uuid.to_string (Uuid.make ()) everywhere.

Yeah, this makes sense

Given that we mostly use strings, where is the compact representation used?

I would like to use the compact representation more often and push strings only for storing to the database, it has the added benefit of specializing the type to a class of objects, e.g. [ `Vm] Uuid.t so they cannot be mixed up.

[edwintorok]

We have to be careful here to keep using a secure way of generating UUIDs, because the session UUID is used as an access token in API calls once a password login has succeeded.
The code here uses /dev/urandom which should be safe enough (except perhaps during early boot).

[edwintorok]

Can you fix the confclits? What remains to be done to get this ready?

[psafont]

I think now it's much better than before, it needs a build for end-to-end testing
SR: 167637 ring3 BST + BVT is all green