txn: lock wait should not consider expired pessimistic locks

[cfzjywxk]

Enhancement

If a pessimistic transaction encounters residual pessimistic locks, it might wait for each lock until the lock timeout expires before attempting to resolve it. Currently, we haven't checked the time-to-live (TTL) of the lock or whether the request carries expiration information.
The https://docs.pingcap.com/tidb/stable/tikv-configuration-file#wait-for-lock-timeout is 1s by default, which means the lock resolve would happen only after the 1s interval. In cases that the transaction coordinator for example the tidb-server crashes, resolving and cleaning the left locks may take a lot of time nearly one lock per 1s.

An improvement in this case is to check the lock TTL first before starts to wait for the lock. If the lock already expires, it's not needed to wait for the lock release and start resolving immediately.

Design

Introduce a scan phase for pessimistic rollback in TiKV, where for pessimistic rollback requests without a specified key, scan all locks associated with the corresponding transaction and perform pessimistic rollback. The kv client can send pessimistic rollback requests without specifying a key.

Related issue: tikv/tikv#16158
Related client-go PR: tikv/client-go#1125