Bug#35105404: Server crashes with signal 11 and asserts in temptable

              code.

Problem: The problem lies in the way MIN/MAX optimization is done.
In the early part of optimization, we try to check whether we can
simply get the minimum or maximum value directly from the index.
For this, we need a key. For derived tables, the key is only updated
in the later part of optimization, when we call JOIN::make_join_plan.
As a result, the MIN/MAX optimization will not be picked, so it won't
Assert on first call. But when the procedure is called a second time,
the keys are updated in keys_in_use_for_query, and the MIN/MAX
optimization picks the index. However, we run into trouble when we try
to initialize the index, because the temporary table handler is not
yet opened. The table handler will only be opened and closed during
the execution phase. This arrangement of code led to an assert.

Solution: At the end of each execution, clear the variables
keys_in_use_for_query, keys_in_use_for_group_by, and
keys_in_use_for_order_by for a temp table. With that, the next
execution will follow the same path as the first.

There was a github contribution from Nicholas Othieno. We have taken
different approach to the fix.

Change-Id: I31107674ffff4e790f4ce269d5197d22c173d29d

Author: mithuncy

sql/sql_union.cc

@@ -2020,8 +2020,12 @@ static void cleanup_tmp_tables(Table_ref *list) {
         tl->table = nullptr;
       } else {
         // Clear indexes added during optimization, keep possible unique index
-        tl->table->s->keys = tl->table->s->is_distinct ? 1 : 0;
-        tl->table->s->first_unused_tmp_key = 0;
+        TABLE *t = tl->table;
+        t->s->keys = t->s->is_distinct ? 1 : 0;
+        t->s->first_unused_tmp_key = 0;
+        t->keys_in_use_for_query.clear_all();
+        t->keys_in_use_for_group_by.clear_all();
+        t->keys_in_use_for_order_by.clear_all();
       }
     }
   }