ESQL: Fix double release in inline stats when LocalRelation is reused

[kanoshiou]

When the optimizer creates a LocalRelation using LocalSupplier.of() (which delegates to ImmediateLocalSupplier), the same page instance can be referenced and released multiple times during inline stats execution. This happens because the LocalRelation serves as a source for both sides of the InlineJoin - once for the left-hand side and again for the right-hand side, causing a double release error and connection closure.

This PR introduces a MaterializeInlineJoinData optimizer rule that runs in the cleanup phase and transforms any LocalRelation nodes on the InlineJoin left-hand side to use CopyingLocalSupplier if they don't already.

Closes #135679

[elasticsearchmachine]

Pinging @elastic/es-analytical-engine (Team:Analytics)

[bpintea]

@kanoshiou thanks for this patch!

I'm however thinking if we shouldn't have another approach here: instead of patching the optimiser rules to use the CopyingLocalSupplier, shouldn't we rather patch theLocalRelation leaf that InlineJoin get to run on the RHS? (Possibly apply the fix only to InlineJoin#firstSubPlan.)
#135679 is INLINE STATS-specific and we could probably contain the fix to it. We could then also check if we'd need a CopyingLocalSupplier (but that's secondary).

@astefan, WDYT?

[astefan]

@kanoshiou thanks for this patch!

I'm however thinking if we shouldn't have another approach here: instead of patching the optimiser rules to use the CopyingLocalSupplier, shouldn't we rather patch theLocalRelation leaf that InlineJoin get to run on the RHS? (Possibly apply the fix only to InlineJoin#firstSubPlan.) #135679 is INLINE STATS-specific and we could probably contain the fix to it. We could then also check if we'd need a CopyingLocalSupplier (but that's secondary).

@astefan, WDYT?

@kanoshiou inline stats is different than any other command in that part of its workings live in EsqlSession. Whenever we add something that is specific to inline stats we try to limit its spread and make it as seamless as possible in the existing code.
This means that modifications that happen outside EsqlSession and InlineJoin itself should be limited. Your changes to optimizer rules that have nothing to do with inline stats (as opposed to PruneInlineJoinOnEmptyRightSide for example which is inline stats specific) should have a very good reason to be there.

Your changes to PruneColumns and PropagateEmptyRelation take the shotgun approach and are too invasive, they will also apply to non-inline stats use cases which is unnecessary. @bpintea's suggestion is something you should look into, instead.

[astefan]

Please, look into @bpintea's suggestion for a less invasive and more targeted approach to this bug fix. Please, let us know if you are able to work on this bug fix in short time, otherwise we are ready to take it over. Thank you.

[kanoshiou]

Thank you for the review and insightful suggestions, @bpintea @astefan! I'll update the branch today with a new logical optimizer rule.