Bug 2141969

Description of problem:

The customer problem described in XFS bz2136497 is triggered by frequent requests for time-based UUIDs from the uuidd daemon. 
The workload (SAP applicaiton) uses the UUIDs for transaction IDs (i.e. as a random generator of unique IDs).
Because libuuid utilizes a file on a hard disk `/var/lib/libuuid.clock.txt` to store last generation timestamps, which create a huge I/O bottleneck for this type of workload.

There is an upstream patch (see below) that omits the file usage when uuidd daemon is awake and running.

Testing from SAP shows tremendous increase in performance, namely throughput on the UUID generation:
~~~
from comment#27 from bz2136497:
"The classic setup, with clock file updates, delivered <430.000 uuid/sec on average
The cont-clock setup delivered >6.800.000 uuid/sec on average"
~~~
Internal tests confirm large performance gains (obviously, as this patch removes IO layer).

This BZ is to backport the cont-clock patch to RHEL8, ideally main and also port to 8.6.z.
RHEL9 BZ will follow :)

The cont-clock patch at https://github.com/util-linux/util-linux.git:
~~~
commit 3cfba7d39b66eff4307218fefd8bb34bb1621f83
Author: Michael Trapp <michael.trapp>
Date:   Mon Jun 20 17:10:36 2022 +0200

    libuuid: Implement continuous clock handling for time based UUIDs
    
    In a uuidd setup, the daemon is a singleton and can maintain it's own
    resources for time based UUID generation. This requires a dedicated
    'clock sequence range' but does not need any further lock/update of
    the LIBUUID_CLOCK_FILE from uuidd. The range of available clock values
    is extended by a continuous handling of the clock updates - instead of
    updating the value to the current timestamp, it is incremented by
    the number of requested UUIDs.
~~~