MDEV-29480 spider group by handler wrong result on order by aggregate…

… alias

when generating a query to send to a remote server, spider generates
new aliases for all tables in the query (at least in the group_by handler).
First it walks all the expressions and create a list of new table aliases
to use for each field. Then - in init_scan() - it actually generates the
query, taking for each field the next alias from the list.

It dives recursively into functions, for example, for func(f1) it'll
go in, will see the field f1 and append to the list the new name for
the table of f1. This works fine for non-aggregate functions and
for aggregate functions in the SELECT list. But aggregate functions
in the ORDER BY are always references to the select list, they never
need to be qualified with a table name. That is, even if there is a
field name as an argument of an aggregate function in the ORDER BY
it must not append a table alias to the list. Let's just skip
aggregate functions when analyzing ORDER BY for table aliases.

This fixes spider/bugfix.mdev_29008
(was observed on aarch64, x86, ppc64le, and amd64 --rr)

storage/spider/spd_group_by_handler.cc

@@ -1857,6 +1857,8 @@ group_by_handler *spider_create_group_by_handler(
         {
           for (order = query->order_by; order; order = order->next)
           {
+            if ((*order->item)->type() == Item::SUM_FUNC_ITEM)
+              continue;
             if (spider_db_print_item_type((*order->item), NULL, spider, NULL, NULL, 0,
               roop_count, TRUE, fields_arg))
             {