Optimizer Trace Replay step #1: dump DDLs of tables/views

This is a part of MDEV-27189.

Step 1 is to dump the DDLs of all tables and VIEWs used in the query.

Use setting optimizer_record_context to enable this.

When enabled, all tables/VIEWs used by the query should be dumped into trace.
Then, one can use JSON_QUERY to extract the definitions.
Then, it should be possible to feed these definitions into the client. This will create
appropriate tables/views. After that, one should be able to run the original query.

Things to note:

• Query may use tables from different databases. This is ok. Make sure DDLs do not rely on the database's character set.
• Tables may be re-created in any order (EDIT: what about foreign keys? Are they printed? If yes, there are restrictions in which order one can run CREATE TABLE statements), VIEWs must be re-created in the "dependency" order: if view1 uses view2, view2 must be created first.
• What about Stored Functions? Dump them too or produce an error?

Current implementation

The new functionality is controlled by @@optimizer_record_context.

The DDLs of used base tables/VIEWs are written into the Optimizer Trace like so:

{ 

  "list_ddls": [

     {

      "name": "",

      "ddl" : "create table t (...)"

     }

    ...

  ]

}

Tables that are used by VIEWs come before their VIEWs.

Code internals

The API is currently just one function:

 void store_table_definitions_in_trace(THD *thd);

Internally it walks the list tables/views used by the query.
It does build a hash table of used dbname.table_name. Currently it's used to avoid printing the same table multiple times. In MDEV-36511, it can be reused to capture/store other table information.

Why store it in Optimizer Trace

• It is just easy to do currently. An alternative could be a table like INFORMATION_SCHEMA.optimizer_context .
• Permissions may be such that one can execute the query but is not allowed to get any details from it, like VIEW definitions. In this case, optimizer trace will be automatically disabled. We get this check done for us now.

TODO

• Review input in the pull request: https://github.com/MariaDB/server/pull/4034
• If the tables have foreign keys, can the list_ddls content be replayed? Not at the moment