After MODIFY COLUMN t NULL, sessions with old schema version can see rows with null when the definition is not null

## Bug Report

Please answer these questions before submitting your issue. Thanks!

### 1. Minimal reproduce step (Required)

Hard to create a normal test case, see [this commit](https://github.com/pingcap/tidb/commit/0c0c7d0785da3f0c9eab53350e86a3879352617b) instead.

It does the following steps:
transaction schema-version>
t0 v0> create table t (a int not null);
t1 v1> alter table t modify column a int null;
t2 vN> insert into t values (null); -- in a node where the new column definition has been made public
t3 vN-1> select a from t; -- can see null, in a node where the new column definition is not yet public
t3 vN-1> show create table t; -- but the table definition says not null?
where vN is the schema version which made the new column definition public.

I.e. a transaction, started on a node with the previous schema version, can see data that is inconsistent with the table definition.

### 2. What did you expect to see? (Required)
I would expect either the insert to fail (if not all nodes have the same visibility of the NULL attribute)
OR
an intermediate state making sure that all rows are consistent with all visible (2) schema versions

But it will never be possible to be fully consistent.
That is unless we somehow block between two schema versions (does not allow the same table to be used with two different schema versions).

Since either one sees a table definition with NULL and that should allow us to insert a NULL
Or we see the table definition with NOT NULL and should not be able to see a NULL.

### 3. What did you see instead (Required)
A row with NULL, while the table definition is NOT NULL.

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

```
tidb_version(): Release Version: v6.5.0-alpha-184-g1cebd1dc56
Edition: Community
Git Commit Hash: 1cebd1dc56b6fabb392874de184648827c5d49fe
Git Branch: master
UTC Build Time: 2022-11-30 15:11:19
GoVersion: go1.19
Race Enabled: false
TiKV Min Version: 6.2.0-alpha
Check Table Before Drop: false
Store: unistore
```
Version which I applied the patch to.