Inconsistent Auto-increment Primary Key Allocation Under Concurrent Operations Violates Transaction Consistency

## Bug Report

Please answer these questions before submitting your issue. Thanks!

### 1. Minimal reproduce step (Required)

CREATE TABLE mtest(c0 DOUBLE, c1 DOUBLE, c2 INT PRIMARY KEY AUTO_INCREMENT) ;
INSERT INTO mtest(c0, c2) VALUES (0.6, NULL);
INSERT INTO mtest(c1, c2) VALUES (0.3, NULL);
/* s1 /BEGIN;
/* s2 /BEGIN;
/* s2 /INSERT IGNORE INTO mtest(c1, c2) VALUES (0.63, NULL);
/* s2 /DELETE FROM mtest WHERE TRUE;
/* s2 /ROLLBACK;
/* s1 /INSERT IGNORE INTO mtest(c0, c1, c2) VALUES (0.11, 0.09, NULL);
/* s1 /COMMIT;

### 2. What did you expect to see? (Required)
mysql> select * from mtest;
+------+------+----+
| c0 | c1 | c2 |
+------+------+----+
| 0.6 | NULL | 1 |
| NULL | 0.3 | 2 |
| 0.11 | 0.09 | 3 |
+------+------+----+
3 rows in set (0.00 sec)
### 3. What did you see instead (Required)
mysql> select * from mtest;
+------+------+----+
| c0 | c1 | c2 |
+------+------+----+
| 0.6 | NULL | 1 |
| NULL | 0.3 | 2 |
| 0.11 | 0.09 | 4 |
+------+------+----+
3 rows in set (0.00 sec)

### 4. Bug Description
Under the REPEATABLE-READ isolation level in TiDB v7.5.1, a specific sequence of concurrent operations (including full-table update, INSERT IGNORE, and a full-table delete followed by a rollback) causes a gap in the auto-increment primary key allocation. This violates transaction consistency because a rolled-back transaction should not have a permanent effect on the auto-increment sequence, leading to discontinuity in the primary key values.

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

| Release Version: v7.5.1
Edition: Community
Git Commit Hash: 7d16cc79e81bbf573124df3fd9351c26963f3e70
Git Branch: heads/refs/tags/v7.5.1
UTC Build Time: 2024-02-27 14:28:32
GoVersion: go1.21.6
Race Enabled: false
Check Table Before Drop: false
Store: tikv |