lost-update data anomaly in repeatable-read isolation for pessimistic transactions

## Bug Report

Please answer these questions before submitting your issue. Thanks!

### 1. Minimal reproduce step (Required)

I tried the following histroy:

case 1:

```
set TXN_ISOLATION = repeatable-read for each session
----------wat_sda_lost_update_c1 test prepare----------
Q0-T1 execute sql: 'DROP TABLE IF EXISTS t1;'
Q0-T1 execute sql: 'CREATE TABLE t1 (k INT PRIMARY KEY, v INT);'
Q0-T1 execute sql: 'INSERT INTO t1 VALUES (0, 0);'
Q0-T1 execute opt: 'COMMIT';

----------wat_sda_lost_update_c1 test run----------
Q1-T1 execute sql: 'BEGIN PESSIMISTIC;'
Q2-T1 execute sql: 'SELECT * FROM t1 WHERE k=0;'
current_result:
(0,0)

Q3-T2 execute sql: 'BEGIN PESSIMISTIC;'
Q4-T2 execute sql: 'UPDATE t1 SET v=2 WHERE k=0;'
Q5-T1 execute sql: 'UPDATE t1 SET v=1 WHERE k=0;'
Q7-T2 execute opt: 'COMMIT';
Q6-T1 execute opt: 'COMMIT';
Q8-T3 execute sql: 'SELECT * FROM t1;'
current_result:
(0,1)
Q9-T3 execute opt: 'COMMIT';
```

case 2:

```
set TXN_ISOLATION = repeatable-read for each session
----------wat_dda_read_write_skew1_c1 test prepare----------
Q0-T1 execute sql: 'DROP TABLE IF EXISTS t1;'
Q0-T1 execute sql: 'CREATE TABLE t1 (k INT PRIMARY KEY, v INT);'
Q0-T1 execute sql: 'INSERT INTO t1 VALUES (0, 0);'
Q0-T1 execute sql: 'INSERT INTO t1 VALUES (1, 0);'
Q0-T1 execute opt: 'COMMIT';

----------wat_dda_read_write_skew1_c1 test run----------
Q1-T1 execute sql: 'BEGIN PESSIMISTIC;'
Q2-T1 execute sql: 'SELECT * FROM t1 WHERE k=0;'
current_result:
(0,0)

Q3-T2 execute sql: 'BEGIN PESSIMISTIC;'
Q4-T2 execute sql: 'UPDATE t1 SET v=2 WHERE k=1;'
Q5-T2 execute sql: 'UPDATE t1 SET v=1 WHERE k=0;'
Q6-T1 execute sql: 'UPDATE t1 SET v=1 WHERE k=1;'
Q8-T2 execute opt: 'COMMIT';
Q7-T1 execute opt: 'COMMIT';
Q9-T3 execute sql: 'SELECT * FROM t1 ORDER BY k;'
current_result:
(0,1) (1,1)

Q10-T3 execute opt: 'COMMIT';
```

### 2. What did you expect to see? (Required)

Both T1 and T2 commit successfully and the final value to 'k=0' in case 1 and 'k=1' in case 2 is **'v=1'**.

### 3. What did you see instead (Required)

One of the transaction in T1 and T2 should be aborted, or the final value to 'k=0' in case 1 and 'k=1' in case 2 is **'v=2'**.

'v=2' is the expected final value because T1 does not read (Q2-T1) the updated value wrote by T2 (Q4-T2 in case 1 and Q5-T2 in case 2) which means T1 should be regarded as happening before T2. Therefore, **the value wrote by T2 should be the latest value.**

### 4. What is your TiDB version? (Required)

v5.4.0