[CALCITE-4512] GROUP BY expression with argument name same with SELECT field and alias causes validation error

[hannerwang]

What changes were proposed in this pull request?

Stop identifiers in a SQL call from being treated as aliases and expanded into select expressions.
For example:
select replace(name, 'a', 'b') as name from users group by replace(name, 'a', 'b')
The name in GROUP BY clause should not be replaced by replace(name, 'a', 'b'), it will be resolved as users.name,
i.e.
select replace(users.name, 'a', 'b') as name from users group by replace(users.name, 'a', 'b')

Why are the changes needed?

Make the sql semantics unchanged when treating identifiers within Group By clause as aliases.
current calcite behavior:
select replace(**name**, 'a', 'b') as **name** from users group by replace(**name**, 'a', 'b')
will be expanded into
select replace(**name**, 'a', 'b') as **name** from users group by replace(**replace(name, 'a', 'b')**, 'a', 'b')
the semantics has been changed.

Does this PR introduce any user-facing change?

No for existing users

[sonarcloud]

Quality Gate passed

Issues
4 New issues
0 Accepted issues

Measures
0 Security Hotspots
97.2% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[suibianwanwank]

Should SqlBasicCall be replaced with SqlCall here. e.g. SqlCase does not inherit SqlBasicCall.

[suibianwanwank]

Same as above.

[mihaibudiu]

@hannerwang I don't know if you have seen the comments in the JIRA.
This PR is very close to being done.
Do you think you can address the comments in time for the next release of Calcite?

I reproduce the comments here:

Which DB are we trying to emulate the behavior of? If so, I would like to see a Quidem test that returns the same in Calcite and that DB, and would return the wrong result if the bug were not fixed. Perhaps something like select mod(empno, 3) as empno from emp group by mod(empno, 2) and make sure that we get the right number of rows.

Also I would like to see a SqlValidatorTest. Something like select date_add('2024-01-01', empno) as empno from emp group by year(empno), where there will be a type error (int vs date) if the wrong column is referenced.

In short, more tests - that are broken before the fix, and pass after the fix, and are demonstrably the same behavior as a given DB - will give me the confidence to approve this PR.