To solve the performance problems seen with the alternate test and similar
contention cases, we need to implement some kind of minimum lock hold time to
ensure that the cluster makes progress even in heavy lock traffic.

Probably we need a user configurable, but with a sensible default, setting which
puts a maximum cap on the minimum lock hold time, and then try to set the lock
hold time automatically using information gathered from the system, such as how
long the wait has been when acquiring the lock, how much work needs to be done, etc.