Truncate table introduce transaction anomaly

## Bug Report

Please answer these questions before submitting your issue. Thanks!

### 1. Minimal reproduce step (Required)
```
t1> create table t (a int primary key);
t1> begin;
t1> insert into t values (1);
t2> truncate table t; -- hangs, waiting on MDL for t1
t3> begin;
t3> insert into t values (1);
t1> commit; -- OK, also allows t2 to finish
t3> commit; -- looks like we inserted a duplicate '1' into t?!?
```

The reason this works internally, is that t1 sees a 'different' table than t3 (they have different Physical Table IDs). The order of the commit of t1 and t3 does not matter here.
But I wonder if this is a correct behaviour?
I don't think there are any DML or DDL that could be done outside of t1 and t3 that would give the same result.

### 2. What did you expect to see? (Required)
Either t1, t2 or t3 fails.

### 3. What did you see instead (Required)
All transactions succeeds and since there are no other transactions the timing between t1 commit and t3 commit suggests that there are no primary key check (from the user perspective) or the DDL is not handling the concurrent transactions to interact with each other.

### 4. What is your TiDB version? (Required)
```
tidb_version(): Release Version: v7.2.0-alpha-244-g0c336cc1ef
Edition: Community
Git Commit Hash: 0c336cc1ef1e2b97ceca96cbfb02175c6bc80b6e
Git Branch: master
UTC Build Time: 2023-05-22 23:19:02
GoVersion: go1.20.4
Race Enabled: false
TiKV Min Version: 6.2.0-alpha
Check Table Before Drop: false
Store: unistore
```