By me:
WL#5257	 	Create a first API for the Optimizer trace
By Jorgen Loland:
WL#5594	 	Add optimizer traces to the range optimizer
WL#5741	 	Ensure optimizer tracing for subqueries works without JSON syntax errors
WL#5581	 	Add --opt-trace-protocol to MTR.
Summary below.
* This feature produces a trace for any SELECT/INSERT/UPDATE/DELETE/DO/SET/CALL,
which contains information about decisions taken by the optimizer during
the optimization phase (choice of table access method, various costs,
transformations, etc). It should help understand the logic followed by the
optimizer for a particular query. Trace is session-local, controlled by the
@@optimizer_trace variable and other new variables, and readable by selecting
from information_schema.optimizer_trace. See the doxygen comments in opt_trace.h
for more info.
* By default the tracing code is compiled in, but not enabled
at runtime; set @@optimizer_trace to enable it.
* Changes to test results: unless otherwise noted they are due to those changes:
** The query printed by EXPLAIN EXTENDED now shows the id of each SELECT,
to help interpret the "id" column.
** EXPLAIN EXTENDED now prints triggered conditions as:
    trigcond_if(outer_field_is_not_null, <is_not_null_test>(`test`.`t2`.`s1`), true)
instead of:
    trigcond(<is_not_null_test>(`test`.`t2`.`s1`).
* @@optimizer_trace_offset is a signed variable, so I had to add support for
this in MySQL (so far all integer system variables were unsigned, it was impossible
to set a system variable to a negative value, it would be rounded to 0).