Bug#30665: Inconsistent optimization of IGNORE INDEX FOR {ORDER BY|GROUP BY}

The optimizer takes different execution paths during EXPLAIN than SELECT,
this fix relates only to EXPLAIN, hence no behavior changes.
The test of sort keys for ORDER BY was prohibited from considering keys
that were mentioned in IGNORE KEYS FOR ORDER BY. This led to two 
inconsistencies: One was that IGNORE INDEX FOR GROUP BY and 
IGNORE INDEX FOR ORDER BY gave apparently different EXPLAINs; the latter 
erroneously claimed to do filesort. The second inconsistency 
is that the test of sort keys is called twice, finding a sort key the first
time but not the second time, leading to the mentioned filesort.

Fixed by making the test of sort keys consider all enabled 
keys on the table. This test rejects keys that are not covering, and for 
covering keys the hint should be ignored anyway.

sql/sql_select.cc

@@ -1695,7 +1695,7 @@ JOIN::exec()
 	  test_if_skip_sort_order(&join_tab[const_tables], order,
 				  select_limit, 0, 
                                   &join_tab[const_tables].table->
-                                    keys_in_use_for_order_by))))
+                                    keys_in_use_for_query))))
       order=0;
     having= tmp_having;
     select_describe(this, need_tmp,
@@ -12614,6 +12614,8 @@ find_field_in_item_list (Field *field, void *data)
   If we can use an index, the JOIN_TAB / tab->select struct
   is changed to use the index.
 
+  The index must cover all fields in <order>, or it will not be considered.
+
   Return:
      0 We have to use filesort to do the sorting
      1 We can use an index.