The purpose of this task is to ensure that the following internal operations
are atomic (either all or nothing) for all storage engines:

Manage .frm
Storage engine data dictionary
Binary log

This will solve the following things:

• .frm context and storage engine dictionary is always in sync
• no #sql-xxxx files if server crashes during alter table
• binary log will always contain the DDL statement if the DDL successfully and committed to the storage engine. If the DDL
  was not successful, all traces of the DDL (like temporary files) will be deleted/rolled back.
  For example, if an alter table was successfully done and committed and we get a crash just before the write to the binary
  log, crash recovery will write the ALTER TABLE command to the binary log. In the case of a crash in the middle of a multi-table drop, crash recovery will write to the binary log those tables that was actually dropped.

The cost of doing the above should not be more than 1-4 sync per DDL.

High level architecture

When doing a DDL, store somewhere (either trough write_ddl_log_entry() or
some new method):

• Operation
• Number of tables
• Table name
• Table id for original table
• Table id for resulting table (in case of rename)
• sql command (for binary log)

If there is no table id (for example for CSV) we would use the
timestamp of the files.

With the above information we would be able to continue from the place
where the operation failed.

Low level architecture is done for each sub project

Some requirements for a storage engine to be 'Atomic compliment':

• drop table and rename_table needs to be either atomic or can be retried if there was a crash in middle of the
  operation.
• Engines supporting inplace alter table, must also support the handlerton->check_version() call to allow the
  ddl recovery code to check if the inline alter table succeed. This is only needed if there was a crash between
  the inplace alter table commit and the rename of the .frm file.

Supported engines in 10.6 are (among others)

• InnoDB
• MyRocks
• Aria (transactional and non transactional tables)
• MyISAM
• Any engine that has only one table file (as then drop and rename will be atomic)