OVER RANGE

Issue:
------
While choosing between ref-access and range-access on the
same index, we prefer range if certain pre-determined
criteria are fulfilled
(See can_switch_from_ref_to_range()).

One such criteria is to choose avoid ref-access if it has
an overly-optimistic / unrealistically low cost. This can
happen when, as in this case, records_per_key is very low.

For this query, ref-access acquires its estimated number
of rows value records_per_key (which is 1) and is
considered to be the cheapest. But in reality the estimate
of range-access which uses more keyparts is accurate
(due to index dives).

So, choosing range-access would be ideal. But the optimizer
choose ref-access.

Solution:
---------
This problem was mostly handled in Bug #23259872.

For 5.7:
--------
Range-access estimates the number of rows to be
1 (correctly) and ref-access arrives at the same number
from records_per_key (incorrectly). Range access is more
accurate and the overhead of using range is also limited.
Hence, choosing range is better than ref, because ref's
estimate is from the less reliable records_per_key.

It is better to use the "<=" rather than "<", to set the
"is_dodgy" flag which is one of the criteria in
can_switch_from_ref_to_range().

For 8.0 and trunk:
------------------
Irrespective of the number of rows estimated for
ref-access, if range-access uses more keyparts, don't
consider this index for ref-access.