• Reuse the range optimization code.

• Reuse existing interfaces to iterate over keyparts and indexes.

• Lift the limitation introduced by mdev-4140 where expensive constant
  subqueries result in rejecting loose scan because they are not evaluated
  during optimization. This can be fixed by delayed evaluation of the
  such constant subqueries during the startup execution phase. In this
  case the range optimizer will not build a range tree, but we could do
  this separately during the execution startup phase.
  A comment from Igor on the fix of MDEV-4140:
  "Yet remember that this fix leads us to a performance regression
  5.2 >> 5.3 when the range expression contains a constant [single-row]
  subquery.

This is due to the changes when and how we build range trees in 5.3.
When we have a range expression with constant expensive subquery we
just bail out and do not include this range into the range condition at all.

The worst thing about this is that we bail out even for dynamic ranges
belonging to te range trees that are build at the execution time when
subquery evaluation is allowed."