Implement cost_for_order_by function10.7-vicentiu-selectivity

The sort length is extracted similarly to how sortlength() function does
it. The function makes use of filesort_use_addons function to compute
the length of addon fields. Finally, by calling compute_sort_costs we
get the fastest_sort possible.

Other changes:
* Sort_param::using_addon_fields() assumes addon fields are already
  allocated. This makes the use of Sort_param unusable for
  compute_sort_costs *if* we don't want to allocate addon fields.

  As a preliminary fix, pass "with_addon_fields" as bool value to
  compute_sort_costs() and make the internal functions use that value
  instead of Sort_param::using_addon_fields() method.

  The ideal fix would be to define a "leaner" struct with only the
  necessary members, but this can be done as a separate commit.

* Remove unnecessary fields from Sort_costs::costs array.
  As we do not yet differentiate between merge sort with fixed length vs
  dynamic length fields, eliminate that differentiation from enum sort_type.
  It can be added at a later date when we indeed have a cost
  differentiation.

* Fixup comments

1 files changed, 2 insertions, 1 deletions

diff --git a/sql/filesort.cc b/sql/filesort.cc
index 54154297a8d..6ff194fd6cf 100644
--- a/sql/filesort.cc
+++ b/sql/filesort.cc
@@ -280,7 +280,8 @@ SORT_INFO *filesort(THD *thd, TABLE *table, Filesort *filesort,
   num_rows= table->file->estimate_rows_upper_bound();
 
   Sort_costs costs;
-  costs.compute_sort_costs(&param, num_rows, memory_available);
+  costs.compute_sort_costs(&param, num_rows, memory_available,
+                           param.using_addon_fields());
 
   if (costs.fastest_sort == NO_SORT_POSSIBLE_OUT_OF_MEM)
   {