Few notes and comments:

1. The text_embedding function is currently the main recipient of this PR at this time. It is supposed to call an external service and create what is, essentially, an array of floats that can be later used in the query
2. due to its nature, the performance of the text_embedding function mainly depends on the external service availability, which can be a bottleneck
3. because this step resembles the one of the enrich policies discovery or lookup indices resolution, it was decided that resolving the text_embedding output value is best placed in the overall "discovery" (index resolution, analyzer, logical optimizer, physical optimizer) set of steps. This set of steps is performed on the coordinator node
4. another argument in favor of using the pre-optimizer step is the one of using the Literal that comes out of the text_embedding function in further optimization rules from the LogicalPlanOptimizer. I personally do not believe this as a strong argument. There could be a similar optimization step on each data node.
5. also, calling the external service has a cost associated with it. One of the arguments in favor of calling this service on the coordinator node only is that the cost is greatly reduced this way. It is essentially one call. There are some downside to this decision:
   • the coordinator becomes a bottleneck
   • some steps that still validate the correctness of the query (everything that comes after the pre-optimization step - logical optimizer, physical optimizer, local logical optimizer, local physical optimizer) can wait unnecessarily a long time before replying back to the user with a potentially invalid query response
   • any shard/index specific optimizations cannot be applied. For example, if the field that is used in the text_embedding function has a null value or no value on some of the shards, I am assuming that calling the external service for that specific value/field is unnnecessary.
6. I think it is OK to start with this pre-optimizer step only for constant values (for example TEXT_EMBEDDING("Who is Victor Hugo?", "test_dense_inference") only from the point of view of calling the external service only once
   • there is also a LocalLogicalPlanOptimizer. If there is any shard/index specific behavior my preference would be to to do this "external service" call from each "relevant" data node or to have a heuristic logic that decides which approach is better: one call from coordinator or multiple calls from each data node.
7. I am not convinced that the EsqlSession should change the way it's handling the Listeners while calling the entire flow of analyzer, logical optimizer, physical optimizer, but I understand the need to have this call async. If it doesn't break any existent tests/behavior it's ok with me.

LGTM