SQL planning: Consider subqueries in fewer scenarios.

[gianm]

Further adjusts logic in DruidRules that was previously adjusted in #13902. The reason for the original change was that the comment "Subquery must be a groupBy, so stage must be >= AGGREGATE" was no longer accurate. Subqueries do not need to be groupBy anymore; they can really be any type of query. If I recall correctly, the change was needed for certain window queries to be able to plan on top of Scan queries.

However, this impacts performance negatively, because it causes many additional outer-query scenarios to be considered, which is expensive.

So, this patch updates the matching logic to consider fewer scenarios. The skipped scenarios are ones where we expect that, for one reason or another, it isn't necessary to consider a subquery.

[imply-cheddar]

What's the reason for the various changes in the tests? They all seem to actually be better plans anyway (well, there's the addition of a filter on an effectively constant virtual column, which I hope primarily ends up as an always-true bitmap and effectively becomes a noop), so I don't think they are problematic. Just wondering if we know why they changed or if it's more of a "well, they changed, but not necessarily in a bad way, so consider it good"?

[gianm]

What's the reason for the various changes in the tests? They all seem to actually be better plans anyway (well, there's the addition of a filter on an effectively constant virtual column, which I hope primarily ends up as an always-true bitmap and effectively becomes a noop), so I don't think they are problematic. Just wondering if we know why they changed or if it's more of a "well, they changed, but not necessarily in a bad way, so consider it good"?

Analysis:

• CalciteQueryTest.testGroupByTimeFloorAndDimOnGroupByTimeFloorAndDim: We're no longer considering plans that involve a filter in an outer query when havingSpec in the inner query would do. So, in this one, an outer filter got pushed into an inner havingSpec.
• CalciteJoinQueryTest.testLeftJoinOnTwoInlineDataSourcesWithTimeFilter, CalciteJoinQueryTest.testLeftJoinOnTwoInlineDataSourcesWithOuterWhere, CalciteJoinQueryTest.testInnerJoinOnTwoInlineDataSourcesWithOuterWhere: These don't use DruidOuterQueryRel (the rel corresponding to the rule that was changed). Likely, the new plan and old plan were considered equally good by the planner, and there's some path-dependency to which one gets picked. So, that's a "well, they changed, but not necessarily in a bad way, so consider it good".