Fix For Select expression aliasing

[GuptaManan100]

Description

Certain select expressions are returning incorrect column names in Vitess. For example, if a user runs SELECT Count (*) from t, Vitess's column name in the output is count(*), even though MySQL would output Count (*). Notice the space and the caseing of count keyword.

This PR proposes a parser fix which tracks the exact string the user used in the query and uses that as the alias for the expression. No planner-side changes are required, since from the planner's perspective this case is indifferent from the one where the user has explicitly added the alias. The planner then handles the aliases properly.

I have added a e2e benchmark to run the Count(*) query multiple times.

Here are the benchmark results for the e2e test and unit tests against main -

pkg: vitess.io/vitess/go/test/endtoend/vtgate/gen4
             │ bench_main_e2e │         bench_fix_e2e         │
             │     sec/op     │   sec/op     vs base          │
CountStar-10      22.41m ± 1%   22.66m ± 1%  ~ (p=0.096 n=20)

pkg: vitess.io/vitess/go/vt/sqlparser
                                  │ bench_main_unit │           bench_fix_unit            │
                                  │     sec/op      │   sec/op     vs base                │
ParseTraces/django_queries.txt-10       761.0µ ± 1%   842.4µ ± 1%  +10.70% (p=0.000 n=20)
ParseTraces/lobsters.sql.gz-10          32.05m ± 1%   33.44m ± 2%   +4.34% (p=0.000 n=20)
ParseStress/sql0-10                     3.572µ ± 0%   4.282µ ± 1%  +19.88% (p=0.000 n=20)
ParseStress/sql1-10                     11.28µ ± 0%   12.73µ ± 1%  +12.87% (p=0.000 n=20)
Parse3/normal-10                        1.749m ± 0%   1.742m ± 0%   -0.43% (p=0.003 n=20)
Parse3/escaped-10                       2.781m ± 0%   2.764m ± 0%   -0.62% (p=0.004 n=20)
geomean                                 410.4µ        441.4µ        +7.54%

                                  │ bench_main_unit │            bench_fix_unit            │
                                  │      B/op       │     B/op      vs base                │
ParseTraces/django_queries.txt-10      557.9Ki ± 0%   584.3Ki ± 0%   +4.73% (p=0.000 n=20)
ParseTraces/lobsters.sql.gz-10         15.65Mi ± 0%   15.91Mi ± 0%   +1.69% (p=0.000 n=20)
ParseStress/sql0-10                    1.392Ki ± 0%   1.884Ki ± 0%  +35.37% (p=0.000 n=20)
ParseStress/sql1-10                    4.186Ki ± 0%   5.244Ki ± 0%  +25.29% (p=0.000 n=20)
Parse3/normal-10                       2.716Ki ± 0%   2.839Ki ± 0%   +4.53% (p=0.000 n=20)
Parse3/escaped-10                      4.914Mi ± 0%   4.914Mi ± 0%   +0.00% (p=0.000 n=20)
geomean                                94.49Ki        105.0Ki       +11.18%

                                  │ bench_main_unit │           bench_fix_unit            │
                                  │    allocs/op    │  allocs/op   vs base                │
ParseTraces/django_queries.txt-10       5.357k ± 0%   6.165k ± 0%  +15.08% (p=0.000 n=20)
ParseTraces/lobsters.sql.gz-10          238.3k ± 0%   248.4k ± 0%   +4.26% (p=0.000 n=20)
ParseStress/sql0-10                      30.00 ± 0%    48.00 ± 0%  +60.00% (p=0.000 n=20)
ParseStress/sql1-10                      82.00 ± 0%   118.00 ± 0%  +43.90% (p=0.000 n=20)
Parse3/normal-10                         58.00 ± 0%    62.00 ± 0%   +6.90% (p=0.000 n=20)
Parse3/escaped-10                        300.0 ± 0%    304.0 ± 0%   +1.33% (p=0.000 n=20)
geomean                                  616.0         739.5       +20.04%

Related Issue(s)

Checklist

• [ ] "Backport to:" labels have been added if this change should be back-ported to release branches
• [ ] If this change is to be back-ported to previous releases, a justification is included in the PR description
• [ ] Tests were added or are not required
• [ ] Did the new or modified tests pass consistently locally and on CI?
• [ ] Documentation was added or is not required

Deployment Notes