ESQL: Avoid regex extract attributes removal

[kanoshiou]

The inputs required by Grok or Dissect might be removed later, so we need to add them separately to the referencesBuilder afterward.

Closes #127468

[elasticsearchmachine]

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

[astefan]

buildkite test this

[kanoshiou]

I'm really confused. I can get a result of 4325287503714500000 when I run the query on my local machine, but the test says it should be 4325287503714500302. It seems the test result is right, I will update the branch.

[astefan]

@kanoshiou I really appreciate you provided this PR and you tried to understand where the fix needs to go.

Unfortunately, this is a trivial fix that doesn't quite catch the true reason for the initial failure.

The essence of the failure is the fact that lookup join can override the type user-provided field with its own type field. The type from eval is of type integer while the type that comes from the lookup join is of type keyword. Because the list of field names didn't contain type the Analyzer couldn't learn about that type that exists in message_types_lookup and the only thing it knew about its type is that it comes from eval.

lookup join (like enrich and maybe inlinestats) are special in the sense that they add some columns to the result, so some of the rules we have in EsqlSession.fieldNames need to be adjusted to account for these special characteristics. Because lookup join can add a field of the same name as type coming from an eval before the said lookup join command, we have a special check in fieldNames that forbids the removal of those Aliases.

Your proposed solution does this:

• places the input references of grok in a new variable, instead of the referenceBuilder that was used before
• the special check above for lookup join is not applied to referenceBuilder for grok because the input reference is not there anymore
• you add to referenceBuilder the content of the grok-special variable

This is a bypass of the lookup join special removal check.

Instead, let the grok references in referenceBuilder where they are and don't let the special lookup join check remove it. The issue is with the lookup join check, not with grok, so adjust that one. I have the feeling that check is applicable in other cases, only that we didn't catch those yet.