Add test to cover the issue that check_txn_status being called on optimistic transaction may lead to transaction consistency issue

[MyonKeminta]

The bug itself is tracked in: tikv/tikv#16620

Consider the test case added in #51667 . Without the fix to tikv, consider the checks at last:

tidb/tests/realtikvtest/txntest/txn_test.go

Lines 529 to 533 in 163bbb0

	assert.Error(t, err)
	assert.Equal(t, errno.ErrWriteConflict, int(errors.Cause(err).(*errors.Error).Code()))
	tk2.MustQuery("select * from t order by id").Check(testkit.Rows("1 11", "2 21"))
	tk2.MustExec("admin check table t2")
	tk2.MustQuery("select * from t2 order by id").Check(testkit.Rows("1 10", "2 11"))

• No error will be received at line 529, where there is supposed to be.
• Check fail at line 531:

              Error:          Not equal:
                              expected: "[1 11]\n[2 21]\n"
                              actual  : "[1 111]\n[2 21]\n"
  

  Which means that atomicity of transaction tk1 (adds 100 to both row 1 and row 2) is broken.
• Data inconsistency will be found at line 532:

              Error:          Received unexpected error:
                              [admin:8223]data inconsistency in table: t2, index: v, handle: 1, index-values:"" != record-values:"handle: 1, values: [KindInt64 11]"
  

  Which is because tk1's write to table t2 (which should be a pair of row and index) is partially committed.