read operations don't wait for resolving secondary locks

[youjiali1995]

Now if a read operation meets a lock, it has to check transaction status and resolve the lock, then it retires to read. Waiting for resolving secondary locks is unnecessary if we can tell TiKV to read through(the lock's transaction is committed) or ignore(the lock's transaction is rolledback) the lock .

[disksing]

It is a good point. I think this improvement can be useful for latency-bound scenarios.

[youjiali1995]

I tested it in a workload that all reads meet a lock belonging to a committed transaction, and I injected 50ms write latency to TiKV. With this improvement, write latency doesn't affect read latency.

PRs are ready for review @sticnarf @MyonKeminta @you06

1. kvproto change: kvrpcpb: add committed_locks to Context to improve resolving locks for pingcap/kvproto#833
2. TiKV supports read-through-lock: *: support read-through lock tikv#11238
3. Unistore supports read-through-lock: unistore: get/batchGet/scan support read-through-lock pingcap/tidb#29898
4. Client-go makes use of it: txnkv: read through locks #380
5. After all PRs are merged, I will update client-go for TiDB.