Add integration test for the issue that stale pessimistic lock request with force-locking enabled may cause data inconsistency after resolving lock

[MyonKeminta]

Ref: tikv/tikv#14551

This PR adds a integration test case to cover the issue stated in tikv/tikv#14551

It's confirmed that the test will fail when running on older TiKV versions without the fix

    lock_test.go:1483:
                Error Trace:    /home/tidb/misono/sync/client-go/integration_tests/lock_test.go:1483
                                                        /home/tidb/misono/sync/client-go/integration_tests/lock_test.go:1510
                                                        /home/tidb/misono/sync/client-go/integration_tests/lock_test.go:1513
                Error:          Received unexpected error:
                                not exist
                                github.com/tikv/client-go/v2/error.init
                                        /home/tidb/misono/sync/client-go/error/error.go:53
                                runtime.doInit
                                        /usr/local/go/src/runtime/proc.go:6506
                                runtime.doInit
                                        /usr/local/go/src/runtime/proc.go:6483
                                runtime.doInit
                                        /usr/local/go/src/runtime/proc.go:6483
                                runtime.doInit
                                        /usr/local/go/src/runtime/proc.go:6483
                                runtime.doInit
                                        /usr/local/go/src/runtime/proc.go:6483
                                runtime.main
                                        /usr/local/go/src/runtime/proc.go:233
                                runtime.goexit
                                        /usr/local/go/src/runtime/asm_amd64.s:1598
                Test:           TestLockWithTiKV/TestStaleForcePessimisticLockNotCommitted
    lock_test.go:1484:
                Error Trace:    /home/tidb/misono/sync/client-go/integration_tests/lock_test.go:1484
                                                        /home/tidb/misono/sync/client-go/integration_tests/lock_test.go:1510
                                                        /home/tidb/misono/sync/client-go/integration_tests/lock_test.go:1513
                Error:          Not equal:
                                expected: []byte{0x76, 0x32}
                                actual  : []byte(nil)

                                Diff:
                                --- Expected
                                +++ Actual
                                @@ -1,4 +1,2 @@
                                -([]uint8) (len=2) {
                                - 00000000  76 32                                             |v2|
                                -}
                                +([]uint8) <nil>

                Test:           TestLockWithTiKV/TestStaleForcePessimisticLockNotCommitted

[cfzjywxk]

Is it better to use resCh := make(chan error, 2) so they two results would not block each other on the result channel?

[cfzjywxk]

As discussed maybe we need to fix BatchResolveLock first and make the resolving behaviour and interface consistent

[MyonKeminta]

Yes. I'll try to find some other way to do this test later.

[MyonKeminta]

This case actually won't happen, since when we meets pessimistic lock, we always call resolvePessimisticLock which only pessimistic-rollback the lock instead of performing normal resolve-lock procedure, and when we meets optimistic lock we always know the real primary.

But perhaps we also need to consider the case that a optimistic lock points to the real primary, but the primary is locked by a stale pessimistic lock pointing to another key which is the invalidated primary...