Remove redundant Aggregate when DISTINCT & GROUP BY are in the same query

[mertak-synnada]

Which issue does this PR close?

Closes #.

Rationale for this change

Inefficient planning is produced when a redundant DISTINCT & GROUP BY clause is used together.

Eg.

EXPLAIN SELECT c3 FROM aggregate_test_100 GROUP BY c3 LIMIT 5;
logical_plan
Limit: skip=0, fetch=5
--Aggregate: groupBy=[[aggregate_test_100.c3]], aggr=[[]]
----Aggregate: groupBy=[[aggregate_test_100.c3]], aggr=[[]]
------TableScan: aggregate_test_100 projection=[c3]
physical_plan
GlobalLimitExec: skip=0, fetch=5
--AggregateExec: mode=Final, gby=[c3@0 as c3], aggr=[], lim=[5]
----CoalescePartitionsExec
------AggregateExec: mode=Partial, gby=[c3@0 as c3], aggr=[], lim=[5]
--------RepartitionExec: partitioning=RoundRobinBatch(4), input_partitions=1
----------AggregateExec: mode=Final, gby=[c3@0 as c3], aggr=[], lim=[5]
------------CoalescePartitionsExec
--------------AggregateExec: mode=Partial, gby=[c3@0 as c3], aggr=[], lim=[5]
----------------RepartitionExec: partitioning=RoundRobinBatch(4), input_partitions=1
------------------CsvExec: file_groups={1 group: [[WORKSPACE_ROOT/testing/data/csv/aggregate_test_100.csv]]}, projection=[c3], has_header=true

Consecutive empty aggregates with same group by are unnecessary.

What changes are included in this PR?

It's fixed that if a distinct is the same as a following group by statement, it should not be turned into an Aggregate plan.

Are these changes tested?

Yes

Are there any user-facing changes?

No

[ozankabak]

I reviewed this and it LGTM. Easy win!

[alamb]

Thank you @mertak-synnada and @ozankabak

[alamb]

These certainly look like bettr plans to me.

However, I wonder if these changes now mean the query doesn't fulfill the original intent of the tests

## Push limit into distinct group-by aggregation tests#

Therefore I wonder if we should add another test like

EXPLAIN SELECT DISTINCT c3, min(c1) FROM aggregate_test_100 group by c3 limit 5;

[ozankabak]

Makes sense

[alamb]

FWIW in my opinion it would be fine to add the other tests as a new PR too

[ozankabak]

Sounds good, let's do it that way