ESQL: Pass Fold context to translatable expressions

[ivancea]

Continuation of #123381

[elasticsearchmachine]

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

[costin]

foldContext is unused.

[ivancea]

It's part of the interface//Override now, as some functions need it

[costin]

See the comment from Andrei.

[astefan]

I do not contest the implementation of the FoldContext idea and how it's being passed around to various functions that need it, but I think it would be beneficial, more elegant and less intrusive throughout the code if we can integrate the FoldContext into the existent infrastructure in a more seamless way. The FoldContext is being passed around in a lot of methods as arguments.

What triggered my curiosity was the fact that the FoldContext is created by a method attached to the Configuration class, which makes it convenient as it's close to the pragma location, but does it actually have a conceptual connection to the Configuration? Can it be made a conceptual element of the Configuration?

This is probably related to the question "What is the lifecycle of a FoldContext? Is the life of a FoldContext the same as the one of the Configuration instance itself? Is the life of a FoldContext the same as the life of a Function instance, as defined by the EsqlFunctionRegistry?".

Could you, please, explore these questions and ideas?
We have a precedence in *QL in the form of EsqlFunctionRegistry.ConfigurationAwareBuilder interface, meaning those functions that need something from the Configuration instance (now function is the only one so far) they have a constructor that injects the configuration into them and they can do whatever they want with it. Since the folding aspect is one tied to a Function, do we actually need the FoldContext that comes from "outside" (in the form of arguments passed to functions - fold being one), or is it possible to use a FoldContext that belongs to a Function instance (and automatically injected through Configuration by the EsqlFunctionRegistry or through another/new interface in EsqlFunctionRegistry) and not pass the context over and over throughout the code?

[astefan]

Here you are still using FoldContext.small().... Shouldn't this use the foldContext instead?

[ivancea]

@astefan I was thinking a bit about it, and I can see some solutions:

1. We could add FoldContext to the functions like we add the Configuration.
2. We could make the config hold a transient context instead of just creating it.
3. We could swap the Configuration in the functions with a FunctionContext, holding all of that, and potential future things. Just to avoid making more overloads.

In all those cases, we end up with this CircuitBreaker-like FoldContext as part of the plan nodes. That's fine; we do that with the CB in other cases. Just commenting because it's the first time we store something like that in the plan I think

I would go with either 2 (store in Configuration) or 3 (new context in functions). Probably 3, as random transient fields feel weird to me if we can avoid them.

@nik9000, any thoughts around this?

[nik9000]

I don't particularly like adding the FoldContext to the functions themselves - the functions are serialized and we need to attach the context on load. We can do it the same way that Configuration works but it feels too clever.

I suppose I like passing it around because it makes us ask "should this fold?" Like, should translation fold? Or should it cast to a Literal? And if the arguments aren't Literal then it waits for the fold rule to do the fold. That way we don't throw away fold results.

[ivancea]

@astefan @nik9000 I've opened a PR (#124894) with the alternate approach of taking the Literals instead