WITH ORDER BY ... LIMIT N

In 5.6, the range optimizer no longer assumes that a simple
range scan is always cheaper than index_merge union scans. 
However, when there is a LIMIT clause, only some rows will
be part of the result. Using an access method that reads rows
in the requested order may therefore be cheaper when the LIMIT
is taken into account.

The first time the range optimizer is run, only properties of 
that single table are taken into account. However, the range
optimizer may be rerun later if the table is first in the join
order and there is a lower LIMIT than the expected number of
rows returned by the access method first decided upon. Before 
this patch, the range optimizer would be rerun with all 
indexes as potential candidates. However, if range access that
does not provide the required ordering is used, early exit 
due to LIMIT is impossible. 

With this patch, only indexes that can be used to fetch rows
in the required order are considered when the LIMIT 
range optimization is run.