File locking threads not entering critical region were "oversleeping"

Instead loser to immediately give up and sleep, should sit a while to enter critical region. This is important for "hot" locks.

Explanation: currently a "loser" will immediately give up and will go to sleep 100ms, even if winner exits critical region within next 5ms (so lost 95ms). The retry is needed to ensure that it is retried as much as given time/unit takes, that was before consumed by constant retries+sleeps. The logic still works, as if tryLock spends time/unit waiting on critical region (which is possible only on VERY HIGHLY congested locks), there will be no retry happening. Still, now it may sleep 5ms, and "win" once "original winner" left the critical region.