It turns out that the standalone PREPARE doesn't call
apply_local_transforms from mysql_prepare_insert, in contrast to
mysql_prepare_delete and mysql_prepare_update.

This has the effect that this resolve phase operation isn't performed when
a standalone prepared insert is performed. Now, at PS execution time, the code
in Sql_cmd_insert::mysql_insert does call apply_local_transforms - for the
first time.  The fact that it is the first call implies this method's call to
fix_prepare_information hasn't been called before.

This again means that the value of st_select_lex::first_execution == true when
we first enter apply_local_transforms (during EXECUTE).

Now, apply_local_transforms tests on this flag in this stanza:

  if (derived_table_count &&
      first_execution &&
      !(thd->lex->context_analysis_only & CONTEXT_ANALYSIS_ONLY_VIEW))
    delete_unused_merged_columns(&top_join_list);

Since first_execution is true, the call to delete_unused_merged_columns is
done.  This is not supposed to have happened, the unused item is no longer
fixed, and the ASSERT happens. Lifting the ASSERT doen't help; we crash later
in sql_authorization.cc:2274 instead.

Adding the call to apply_local_transforms at the end of
mysql_prepare_insert makes the statement work, since we now do the work of
apply_local_transforms also at prepare time, as for DELETE and UPDATE.

We only do this if mysql_prepare_insert is not called for a INSERT..SELECT
since for those statements, apply_local_transforms *are* called during
prepare already (from st_select_lex_unit::prepare), and calling it can cause
things to break, e.g. one of the tests for WL-5275 in insert.test,
cf. discussion on the bug entry.

This patch also fixes Bug#21696641, so test cases have been added for
both 21696206 and 21696641.