*: Provide a util to "pause" session in uint test

[lcwangchao]

What problem does this PR solve?

Issue Number: close #35526

Problem Summary:
Make the session be able to "pause" during uint test.

What is changed and how it works?

This PR provide a util to pause session in uint test. If we want to do pause, we should do following things:

1. Inject a "StopPoint" into code by using InjectSessionStopPoint
2. In the unit test, use EnableGlobalSessionStopFailPoint to enable the related fail point.
3. Use testkit.NewStoppableTasksRunner(t).CreateSteppedTestKit to create a new stepped testkit. Different with the normal testkit, it provides method SteppedMustQuery and SteppedMustExec to execute a sql step by step.
4. Calltk.EnableSessionStopPoint(stopPoint1, stopPoint2, ...) before if you want to run a sql and pause it in the middle.
5. Call tk.SteppedMustQuery or tk.SteppedMustExec to run a sql, and it will return SteppedCommandTask
6. The returned task object will be stopped at the first stop point it meet, and you can use task.ExpectStoppedAt to check the current stop point.
7. Use task.Continue() to make the command continue to run.

For example, if you want to test the behavior that another session updates the record after the specified stop point, you can:

// EnableGlobalSessionStopFailPoint should be called before we want to pause sessions
taskstop.EnableGlobalSessionStopFailPoint()

// Create a stepped test kit
tk := testkit.NewStoppableTasksRunner(t).CreateSteppedTestKit("name", store)

// stop1, stop2 is two stop points we pre injected
tk.EnableSessionStopPoint("stop1", "stop2")

// Execute the sql you want to test, and it will stop at the first stop point it meet
task := tk.SteppedMustQuery("select * from t where id=1 for update")
task.ExpectStopAt("stop1")

// When the task paused, we can update the record in another session
tk2.MustExec("update t set v=v+1 where id=1")

// We can use `Continue` to resume a task and it will go on and pause at next stop point
task.Continue().ExpectStopAt("stop2")

// When the task finished, it has a done status.
task.Continue().ExpectDone()

// You can use task.GetQueryResult() to get back the result of query
task.GetQueryResult().Check(...)

// Do not forget to close the stepped testkit in the end
tk.Close()

Check List

Tests

• Unit test

Release note

Please refer to Release Notes Language Style Guide to write a quality release note.

None

[ti-chi-bot]

[REVIEW NOTIFICATION]

This pull request has been approved by:

• tiancaiamao
• xhebox

To complete the pull request process, please ask the reviewers in the list to review by filling /cc @reviewer in the comment.
After your PR has acquired the required number of LGTMs, you can assign this pull request to the committer in the list by filling /assign @committer in the comment to help you merge this pull request.

The full list of commands accepted by this bot can be found here.

Reviewer can indicate their review by submitting an approval review.
Reviewer can cancel approval by submitting a request changes review.

[sre-bot]

Please follow PR Title Format:

• pkg [, pkg2, pkg3]: what is changed

Or if the count of mainly changed packages are more than 3, use

• *: what is changed

After you have format title, you can leave a comment /run-check_title to recheck it

[sre-bot]

Code Coverage Details: https://codecov.io/github/pingcap/tidb/commit/2f11a051e4332bf7ed4765e232d44cf86fbd7fc6

[sre-bot]

Please follow PR Title Format:

• pkg [, pkg2, pkg3]: what is changed

Or if the count of mainly changed packages are more than 3, use

• *: what is changed

After you have format title, you can leave a comment /run-check_title to recheck it

[sre-bot]

Please follow PR Title Format:

• pkg [, pkg2, pkg3]: what is changed

Or if the count of mainly changed packages are more than 3, use

• *: what is changed

After you have format title, you can leave a comment /run-check_title to recheck it

[sre-bot]

Please follow PR Title Format:

• pkg [, pkg2, pkg3]: what is changed

Or if the count of mainly changed packages are more than 3, use

• *: what is changed

After you have format title, you can leave a comment /run-check_title to recheck it

[sre-bot]

Please follow PR Title Format:

• pkg [, pkg2, pkg3]: what is changed

Or if the count of mainly changed packages are more than 3, use

• *: what is changed

After you have format title, you can leave a comment /run-check_title to recheck it

[lcwangchao]

/run-unit-test

[lcwangchao]

@xhebox I've simplified the implement and PTAL again. In the current implement I put every command run in a single goruntine and Exec and MustExec will run in the main goruntine like normal TestKit . I did not embeded it into TestKit because it seems more works to make it thread safe for all the methods. So now only MustExec and MustQuery is opened to user but I think it is enough.

[lcwangchao]

/rebuild

[lcwangchao]

/run-mysql-test

[xhebox]

LGTM

[tiancaiamao]

@lysu and I also wrote something like this in the past
https://github.com/tiancaiamao/debugger/blob/master/debugger.go
and here #22434

But there are mental burden for other programmers to learn and use the API to write test.
So in the end, most of the programmers choose to just use failpoint [+ global variable] + mutex / channel for the testing scenario. Anyway, the test code is ugly, but not too hard to comprehend.

A: Why the test code so ugly
B: Everyone do it the quick and dirty way, the logic spread over different code fragments
A: I gonna fix it by writing a lib so others use the write tests in a uniform way
...
C: Who write the test code in this way? To understand the test code, I have to read the lib implementation first.
B: Yes, now we have two problem to solve.

[lcwangchao]

@lysu and I also wrote something like this in the past https://github.com/tiancaiamao/debugger/blob/master/debugger.go and here #22434

But there are mental burden for other programmers to learn and use the API to write test. So in the end, most of the programmers choose to just use failpoint [+ global variable] + mutex / channel for the testing scenario. Anyway, the test code is ugly, but not too hard to comprehend.

A: Why the test code so ugly B: Everyone do it the quick and dirty way, the logic spread over different code fragments A: I gonna fix it by writing a lib so others use the write tests in a uniform way ... C: Who write the test code in this way? To understand the test code, I have to read the lib implementation first. B: Yes, now we have two problem to solve.

Yes, the previous implement for this PR is more abstract and independent with tidb session and testkit, but then I found it's a little hard to use in most cases because you should connect it with testkit manually. So I changed the way and make it a little easier. For example if we want to test a retry should happen it can be:

tk1 := testkit.NewSteppedTestKit(t, store)
tk2 := testkit.NewTestKit(t, store)
tk1.SteppedMustQuery("select * from t where id=1 for update").ExpectStoppedOn("beforeExecute")
tk2.MustExec("update t set v=v+1 where id=1")
tk1.Continue().ExpectStoppedOn("lockErrorRetry")
tk1.Continue().GetQueryResult().Check(testkit.Rows("1 11"))

Maybe it's easier.

[lcwangchao]

/run-check_dev_2

[lcwangchao]

/merge

[ti-chi-bot]

This pull request has been accepted and is ready to merge.

Commit hash: 09d4bbd

[sre-bot]

TiDB MergeCI notify

CI Name	Result	Duration	Compare with Parent commit
idc-jenkins-ci/integration-cdc-test	🟢 all 35 tests passed	24 min	Existing passed
idc-jenkins-ci-tidb/integration-common-test	🟢 all 11 tests passed	18 min	Existing passed
idc-jenkins-ci-tidb/common-test	🟢 all 12 tests passed	11 min	Existing passed
idc-jenkins-ci-tidb/sqllogic-test-2	🟢 all 28 tests passed	8 min 30 sec	Existing passed
idc-jenkins-ci-tidb/sqllogic-test-1	🟢 all 26 tests passed	7 min 21 sec	Existing passed
idc-jenkins-ci-tidb/integration-ddl-test	🟢 all 6 tests passed	7 min 10 sec	Existing passed
idc-jenkins-ci-tidb/tics-test	🟢 all 1 tests passed	6 min 22 sec	Existing passed
idc-jenkins-ci-tidb/mybatis-test	🟢 all 1 tests passed	3 min 2 sec	Existing passed
idc-jenkins-ci-tidb/integration-compatibility-test	🟢 all 1 tests passed	2 min 42 sec	Existing passed
idc-jenkins-ci-tidb/plugin-test	🟢 build success, plugin test success	4min	Existing passed