TODO: handle_query is deleted about mysql-server-mysql-8.0.30 HOT 2 OPEN

Bug#32079103: Assertion failure: trx->lock.table_locks.empty()

The symptom for this problem is that we may have an inconsistent
InnoDB transaction after creating a non-InnoDB table from a
query expression that operates on InnoDB tables.
The cause of this is the refactoring that moved creating the
new table into Query_result_create::start_execution().
Before that, the new table was created in
Query_result_create::prepare(), however with single preparation,
it could not be created as part of query preparation.

The problem with the new strategy was that table creation would
occur after locking the tables of the query expression, and thus
the implicit commit of the table creation would clear the locks.
As a result, evaluating the query expression would access unlocked
InnoDB tables, leading to an inconsistent InnoDB state.
When the session was immediately terminated, the InnoDB transaction
state checker would report a problem.

The solution to the problem is to remove the table creation from
Query_result_create::start_execution() and place it in a new function
Query_result_create::create_table_for_select(). We also implement a
**simplified version of handle_query() called populate_table()**, since
the former is not really designed for DDL statements that perform
intermediate commits.

**handle_query() itself is removed because it is no longer in use.**

Reviewed by: Gopal Shankar <[email protected]>
Reviewed by: Chaithra Gopalareddy <[email protected]>