- Generate correct contents of `Extra` column for UPDATEs/DELETEs that use quick selects
- UPDATEs with used_key_is_modified=true will show "Using buffer"

- Update test results after last few csets
- Generate correct value for `possible_keys` column for single table UPDATE/DELETE.

- if EXPLAIN DELETE prints "Deleting all rows", it should show the 
  expected number of rows in the rows column.

- Add support for EXPLAIN INSERT.

- Better EXPLAIN-saving methods for quick selects

- Run probes like MYSQL_INSERT_SELECT_START or 
  MYSQL_MULTI_DELETE_START for EXPLAIN, too.
  We should run them, because 1. EXPLAIN SELECT does it, and 
  2. MySQL also does it.

- Handle the case when EXPLAIN UPDATE/DELETE has pruned away all partitions.

- Address review feedback: more renames

- Address review feedback: rename files

- Address review feedback: rename nearly any name used by the new EXPLAIN code.

- Added a testcase

- Make EXPLAIN {PARTITIONS,EXTENDED} {UPDATE,DELETE} work.

- Make EXPLAIN UPDATE/DELETE work inside SPs
- Return correct error code from mysql_delete()
- EXPLAIN <multi-DELETE> will create a multi_delete object (as it 
  affects the optimization). select_result will be only used for 
  producing EXPLAIN output.

- Query plan footprint (in new terms, "EXPLAIN structure") should always keep 
  a copy of key_name.  This is because the table might be a temporary table which
  may be already freed by the time we use query plan footprint.

- If we're running explain with flags, use the same set of flags to make EXPLAIN columns 
  and contents.

- Add EXPLAIN output print out for INSERT/REPLACE ... SELECT

- update mysqld--help.result

- Don't forget to delete the query plan footprint when 
  the query wasn't printed into slow query log for some reason
- ALso removed some garbage code.

- Don't print a plan when the statement didn't produce it
- Also, add first testcase. We can't check the EXPLAIN from the slow log itself, though.

- Initial implementation. 

- Make QPF structures store data members, not strings. 
  This is not fully possible, because table names (and hence 
  key names, etc) can be deleted, and we have to store strings.

- Post-merge fixes (conflict with DELETE .. RETURNING)
- Add a testcase with EXPLAIN ... DELETE ... RETURNING

- Merge with current 10.0-base

- Merge with current 10.0-base

Implement @@gtid_binlog_state. This is the internal state of the binlog
(most recent GTID logged for every domain_id and server_id). This allows
to save the state before RESET MASTER and restore it afterwards.

The ignored events are not written to the relay log, but instead a fake
Rotate event is generated to handle update of position.

Extend this for Gtid so we similarly generate a fake Gtid_list event
to update the GTID position.

Also fix an unrelated test issue that got triggered by the added test cases.

- Let sp_get_flags_for_command() set sp_head::MULTI_RESULTS for DELETE ... RETURNING, 
  like it does for all statements that return a resultset.

  
Currently the loose scan code in opt_range.cc considers all indexes as
possible for the access method. Due to inexact statistics it may happen
that a loose scan is selected over a unique index.
  
This is clearly wrong since a "loose scan" over a unique index will read
the same keys as a direct index scan, but the loose scan has more overhead.
  
This task adds a rule to skip unique indexes for loose scan.

It was fixed as merge changes for MDEV-4811.

bMDEV-4906: When event apply fails, next SQL thread start errorneously commits the failing GTID to gtid_slave_pos

When a GTID event is executed, we remember the contained GTID position so that
when we have applied the entire event group we can commit it to
gtid_slave_pos.

However, if the event group fails to apply due to some error and the SQL
thread aborts, the code did not correctly clear the remembered GTID. Thus,
when SQL thread was restarted, the old GTID of the failing event group was
incorrectly updated to gtid_slave_pos when the initial rotate event was
executed, corrupting the GTID position.