Remove EnforceSingleRowNode support from PlanNodeDecorrelator

[sopel39]

EnforceSingleRowNode guarantees that exactly single row is produced. Therefore, PlanNodeDecorrelator was incorrectly removing EnforceSingleRowNode even if decorrelated subplan could produce 0 rows.
Additionally, TransformCorrelatedJoinToJoin was completing with TransformCorrelatedScalarSubquery to decorrelate EnforceSingleRowNode.
This changes removes support for EnforceSingleRowNode from PlanNodeDecorrelator and makes TransformCorrelatedScalarSubquery the only rule that (correctly) decorrelates that node.

[sopel39]

This is mostly cleanup, I don't think it's possible to produce wrong plan with this issue.

[sopel39]

Fixes #19002

[findepi]

Fixes #19002

This issue is closed.
Should it be reopened?

[findepi]

cc @kasiafi @kokosing for decorrelation

[sopel39]

This issue is closed.
Should it be reopened?

@findepi this PR is the "proper" fix to the underlying issue (#19002 was not addressing the issue of wrong planning covered by this PR).

However, regression introduced by #19002 was covered in #19922

[martint]

There's no guarantee that there's an EnforceSingleRowNode, is there? All this rule cares about is whether the subplan is known to produce 0 or 1 row.

[findepi]

if there is no EnforceSingleRowNode, we exit earlier:

        if (!searchFrom(subquery, context.getLookup())
                .where(EnforceSingleRowNode.class::isInstance)
                .recurseOnlyWhen(ProjectNode.class::isInstance)
                .matches()) {
            return Result.empty();

[martint]

I missed that. It wasn't immediately visible in the diff. However, that should not be necessary for this rule to work in general, as far as I can tell. We omit that check and rely on the cardinality property of the subplan.

I guess my comment is that in order to future-proof this comment from non-local changes, we could just generalize it to say that the subplan is guaranteed to produce one row (regardless of how that's achieved), so this can be an inner join instead of a left join.

[findepi]

I guess the rule insists on finding EnforceSingleRowNode because it also wants (needs?) to remove it.

[sopel39]

Ideally for this rule we have two sub-rules like ...WithProjection and WithoutProjection as for example for TransformCorrelatedGlobalAggregationWithoutProjection. However, I don't want to refactor this rule as part of this PR.

I guess my comment is that in order to future-proof this comment from non-local changes, we could just generalize it to say that the subplan is guaranteed to produce one row (regardless of how that's achieved), so this can be an inner join instead of a left join.

I don't think it can be generalized like that in a sense that EnforceSingleRowNode is kind of special node, because:

1. subplan might produce more than one row and EnforceSingleRowOperator will fail then. That check is preserved in decorrelated plan after TransformCorrelatedScalarSubquery. Such check is not needed while decorrelating via PlanNodeDecorrelator.
2. subplan might produce 0 rows and EnforceSingleRowOperator will produce null row then. This semantics is also preserved by TransformCorrelatedScalarSubquery (and it's only possible to decorrelate such plan when join itself has no filter).

Overall, single-row cases are already handled by TransformCorrelatedJoinToJoin (and PlanNodeDecorrelator) while this rule is dedicated for decorrelation of EnforceSingleRowNode