derived_handler::keep_after_optimize: an engine may give a derived table back once its plan is known

A derived_handler is chosen at prepare (find_derived_handler in mysql_derived_prepare), before any plan exists, yet the server optimizes the specification of a pushed derived table anyway. The new hook shows the engine that plan and lets it decline the pushdown.

API (sql/derived_handler.h)
{{virtual bool keep_after_optimize(JOIN *join)

}}

• join is the JOIN of the derived table's specification
• default true: no change for existing engines

On false (in mysql_derived_optimize, right after join->optimize())

• if the table is streamed, TABLE_LIST::unstream_derived() restores the temporary table's own handler (same steps that make_aggr_tables_info used, now factored out)
• pushdown_derived and dt_handler are deleted; the server materializes the table itself
• the select's explain type and plan are saved again, so EXPLAIN/ANALYZE show DERIVED with its own tables instead of PUSHED DERIVED

Scope

• called only for a single-SELECT derived table, not for a UNION/INTERSECT unit
• runs during the outer select's DT_OPTIMIZE, before the outer make_join_statistics/choose_plan, so the outer plan sees the materialized table

Open point (from code reading, not tested): for a splittable specification JOIN::optimize() stops after phase 1 (OPTIMIZATION_PHASE_1_DONE), so the engine receives a join whose order is chosen but get_best_combination() has not run; stage 2 (mysql_derived_optimize_stage2) does not call the hook.

Commits (branch orthus/derived-late-decline, MariaDBEnterprise)

• 75a9581d3bc derived_handler: an engine may give a derived table back once its plan is known
• 374f87fbc21 derived_handler: EXPLAIN shows the plan of a table given back late