The purpose of this task is to ensure that DROP DATABASE is crash safe.

This means that if the server is killed during drop database crashes , the database and binary log will be consistent when the server has done engine and ddl recovery.
All tables that where already dropped or started to be dropped will be fully dropped and binary logged.
Before this task there was a change that one could, after a crash, have stray .frm files
and dropped tables was not binary logged.

For this particular project, we will ensure that every executed DROP TABLE is atomic and will be logged to the binary log.

This is the same behaviour that we have with multi-table DROP TABLE.
Making DROP DATABASE atomic (either everything is dropped or nothing) will be fixed in a future task.

Description of how the current task should work:

• Collect list of tables
• DDL log tables as they are dropped
• DDL log drop database
• Delete db.opt
• Delete data directory
• Deactive ddl log entry

This is in line of how things are now (minus ddl logging) except that
we delete db.opt file last to not loose it if DROP DATABASE fails.

On recovery we have to ensure that all dropped tables are logged in
binary log and that they are properly dropped (as with atomic drop
table).
No new tables be dropped as part of recovery.

Recovery of active drop database ddl log entry:

• Update binary log with dropped tables. If table list is longer than
  max_allowed_packet, then the query will be split into multiple drop queries.
• If drop database was ddl logged but not in binary log
• drop the db.opt file and database directory.
• Log into the binary log