planner: enhance the rule max_min_eliminate to support multiple agg (#12083)

[francis0407]

What problem does this PR solve?

cherry-pick #12083

conflicts:
planner/core/rule_max_min_eliminate.go
planner/core/logical_plans.go
planner/core/testdata/plan_suite_out.json

The major difference between release-3.0 and master branch which this PR encounters is:
In master,

// For index paths, we have to check:
// 1. whether all of the conditions can be pushed down as accessConds.
// 2. whether the AccessPath can satisfy the order property of `col` with these accessConds.
result, err := ranger.DetachCondAndBuildRangeForIndex(p.ctx, conditions, path.FullIdxCols, path.FullIdxColLens)
if err != nil || len(result.RemainedConds) != 0 {
	continue
}

But in release-3.0, AccessPath does not have fullIdxCols, so I use expression.IndexInfo2Cols(p.schema.Columns, path.index) to generate idxCols instead.

// For index paths, we have to check:
// 1. whether all of the conditions can be pushed down as accessConds.
// 2. whether the accessPath can satisfy the order property of `col` with these accessConds.
idxCols, idxColLens := expression.IndexInfo2Cols(p.schema.Columns, path.index)
if len(idxCols) == 0 {
	continue
}
result, err := ranger.DetachCondAndBuildRangeForIndex(p.ctx, conditions, idxCols, idxColLens)
if err != nil || len(result.RemainedConds) != 0 {
	continue
}

What is changed and how it works?

Check List

Tests

• Unit test

Side effects

• Possible performance regression
• Increased code complexity

Release note

• Optimize max/min queries which contain more than one max/min.
  For example,

select max(a), min(a) from t

will be rewritten as

select * from
  (select a from t order by a desc limit 1),
  (select a from t order by a limit 1)

[eurekaka]

LGTM

[francis0407]

/run-unit-test

[winoros]

lgtm

[eurekaka]

/merge

[sre-bot]

/run-all-tests