[fix](having-clause) having clause do not works correct with same alias name

[cambyzju]

Proposed changes

Issue Number: close #15142

Problem summary

Describe your changes.

Checklist(Required)

1. Does it affect the original behavior:
   • Yes
   • No
   • I don't know
2. Has unit tests been added:
   • Yes
   • No
   • No Need
3. Has document been added or modified:
   • Yes
   • No
   • No Need
4. Does it need to update dependencies:
   • Yes
   • No
5. Are there any changes that cannot be rolled back:
   • Yes (If Yes, please explain WHY)
   • No

Further comments

If this is a relatively large or complex change, kick off the discussion at dev@doris.apache.org by explaining why you chose the solution you did and what alternatives you considered, etc...

[hello-stephen]

TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 34.92 seconds
load time: 634 seconds
storage size: 17123043839 Bytes
https://doris-community-test-1308700295.cos.ap-hongkong.myqcloud.com/tmp/20221221131027_clickbench_pr_66362.html

[morningman]

please add regression test

[cambyzju]

please add regression test

done

[morrySnow]

MySQL's behavior is very strange. according to sql standard, having should filter the data after Aggregate. So the slot in having should always bind on the output of Aggregate, in other words, the alias name.
Since doris has many different from the behavior of MySQL. Here we should follow the SQL standard instead of MySQL for a more understandable syntax.

[cambyzju]

MySQL's behavior is very strange. according to sql standard, having should filter the data after Aggregate. So the slot in having should always bind on the output of Aggregate, in other words, the alias name. Since doris has many different from the behavior of MySQL. Here we should follow the SQL standard instead of MySQL for a more understandable syntax.

1. accord to SQL standard, having clause do not support alias name;
2. Doris always say "compatible with MySQL protocol", lots of SQL keeps Mysql way;
3. Before this pr, we already try to following MySQL way. But the old implement has two problem:

• one is, only consider has GROUP BY or NOT, not consider slots inside GROUP BY or not;
• the other is, try whole HAVING expr, do consider part slots have alias, part slots do not;

So if we want to follow SQL standard, we should better forbid alias name in HAVING clause.
But old users will confused, because the behavior changes too large.

[yangzhg]

LGTM

[github-actions]

PR approved by at least one committer and no changes requested.

[github-actions]

PR approved by anyone and no changes requested.