[NSAmelchev]

A timed out GridDhtColocatedLockFuture completes without synchronizing with the mapping thread: if the timeout expires while the keys are still being mapped, undoLocks finds nothing yet and the mapping then registers the candidates for the completed future. tryLock returns false, but the key stays locked with no owner, and the next partition map exchange waits for it forever. A reentry of a key the thread already holds leaks the same way.

Changes

• The mapping and cancel() of an explicit lock are serialized with the timeout callback on the timeout object monitor: a completed future registers nothing, everything registered before is undone by the completion. Transactions are not affected, they release their candidates on rollback.
• A key the thread already holds is reentered when the lock is acquired, not during the mapping: a failed attempt has nothing to release on it.

Visible behavior: tryLock(timeout) paused during mapping longer than the timeout may return true after the timeout instead of returning false and leaving the key locked.