[FEATURE] Support flexible grouping order in aggregation including span

[xinyual]

Is your feature request related to a problem?
When query using PPL, we find
source=opensearch_dashboards_sample_data_logs |stats COUNT() as cnt by span(timestamp, 1d), response could work but source=opensearch_dashboards_sample_data_logs |stats COUNT() as cnt by response， span(timestamp, 1d) fails. It is unreasonable because the order should not influence the execution result. It works well if span is not included

What solution would you like?
Support flexible order when including span

[LantaoJin]

Span will always be the first grouping expression in grouping list in current implementation.
Microsoft Kusto Query Language (KQL) has similar behavior. (You can try here with below quoted statements)

StormEvents
| summarize avg(DamageProperty) by bin(StartTime, 1d), State, EventType

and

StormEvents
| summarize avg(DamageProperty) by State, EventType, bin(StartTime, 1d)

both use StartTime bin as the first grouping key in results. But all queries could be executed.

PPL query

source=opensearch_dashboards_sample_data_logs | stats COUNT() as cnt by response, span(timestamp, 1d)

fails with SyntaxCheckException that seems not make sense.

[LantaoJin]

The stats syntax in our official document doesn‘t state that span must be the first expression of by-clause. But its order is declared in stats.rst as a design from #417.

sql/docs/user/ppl/cmd/stats.rst

Line 42 in 3ab7851

* Syntax: by [span-expression,] [field,]...

Based on current implementation, span is a dedicated member of Aggregation(UnresolvedPlan), rather than a part of groupExprList. The span member variable will be filled into the first grouping key when converting to LogicalAggregation.
Should we support this enhancement? Any thoughts @penghuo ?

[dblock]

[Catch All Triage - Attendees 1, 2, 3, 4, 5]