[DNM] refine handle table scan

[SeaRise]

What problem does this PR solve?

Issue Number: ref #4118

Problem Summary:

What is changed and how it works?

• remove the use of DAGQueryBlock in DAGStorageInterpreter
• move StorageWithStructureLock(table metadata and table lock) from DAGStorageInterpreter to TiDBStorageTable.

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No code

Side effects

• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Breaking backward compatibility

Documentation

• Affects user behaviors
• Contains syntax changes
• Contains variable changes
• Contains experimental features
• Changes MySQL compatibility

Release note

None

[ti-chi-bot]

[REVIEW NOTIFICATION]

This pull request has not been approved.

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.

[SeaRise]

/run-integration-test

[JaySon-Huang]

Why not just use the table_scan->executor_id() but save a copy of query_block.source_name as the executor_id?

[SeaRise]

For coprocess read, table_scan->executor_id() may be empty.
query_block.source_name is guaranteed not to be empty(If executor_id is empty, an id will be assigned).
Would it be better to share the same executor_id for local read and remote read?

[SeaRise]

/run-integration-test

[SeaRise]

/run-integration-test

[windtalker]

This pr locks the table before doing learner read, this is the same as our first implemention, but we met some deadlock related issue, and this pr moved the lock table logical after leaner read is done. So maybe we should not lock the table so early. @JaySon-Huang could you please reconfirm this?

[SeaRise]

This pr locks the table before doing learner read, this is the same as our first implemention, but we met some deadlock related issue, and this pr moved the lock table logical after leaner read is done. So maybe we should not lock the table so early. @JaySon-Huang could you please reconfirm this?

Maybe I need to move learner read to TiDBStroageTable too

[JaySon-Huang]

@SeaRise I prefer to do it this way SeaRise#1

1. Only gets and locks storage(s) after learner read, and add comments about why
2. DAGQueryBlockInterpreter does not know about "TiDBStorageTable" except that inside DAGQueryBlockInterpreter::handleTableScan, receive a ptr to take over the locks
3. Make the ctor of TiDBStorageTable to be more simple, use a static method instead

[SeaRise]

/hold