Avoiding re-creation of uuid_t state with OSSP UUID

While mucking around with contrib/uuid-ossp, I realized that its usage
of the OSSP UUID library is really rather broken: it creates and destroys
a uuid_t object for each call of the UUID creation functions. This is not
the way you're supposed to use that library. The uuid_t object is meant
to hold persistent state such as the system MAC address, so really we
ought to make such an object once per session and re-use it, as per the
attached proposed patch. Doing it like this has multiple benefits:

* saving the cycles needed to create and destroy a uuid_t object, notably
including kernel calls to find out the system's MAC address. On my
machine, this patch reduces the runtime of uuid_generate_v1() from about
16 microseconds to about 3.

* reducing the amount of entropy we draw from /dev/urandom. strace'ing
shows that at least with RHEL6's version of OSSP UUID, each uuid_create
call reads 2 bytes from /dev/urandom, thus depleting the available
entropy system-wide.

* enabling the code to actually guarantee that successive V1-style UUIDs
are distinct. OSSP remembers the last timestamp it read from the kernel,
and if the new one is the same, it increments the saved "clock sequence"
value to guarantee a distinct result. But that logic all depends on
re-using a cached uuid_t! Without that, if successive gettimeofday calls
produce the same result, we're at risk of producing duplicate UUIDs if
the clock sequence values are the same. uuid_create does initialize the
clock sequence value to a random number, but since only 14 bits are
available for it in the V1 UUID format, the chance of collision is 1 in
16K. Now admittedly you'd need a machine noticeably faster than mine to
get duplicate timestamps with the existing code, but we're not that far
away from having it happen.

So I think the existing code is not only rather broken, but its effects
on the system entropy pool are not far short of being a security bug.
Accordingly, I'd like to not only apply this to HEAD but back-patch it.
Comments?

regards, tom lane