ES|QL: Remove implicit limit in FORK branches in CSV tests

[ioanatia]

We only remove the implicit limit we add to FORK branches, when the tests are running under snapshot (with a 50% chance, since we randomize this).
The more interesting case is when we running GenerativeForkIT which reuses all the existing CSV tests to generate new queries using FORK.

When I removed the implicit limit, I noticed that GenerativeForkIT started failing with unbounded SORT errors.
For example:

FROM semantic_text
| KEEP semantic_text_field
| sort semantic_text_field asc;

will get transformed into:

FROM semantic_text
| KEEP semantic_text_field
| sort semantic_text_field asc;
| FORK (WHERE true) (WHERE true)
| WHERE _fork == \"fork1\"
| DROP _fork 

This query would then fail because the SORT is not bounded by a LIMIT and we cannot execute it.

I had to adjust GenerativeForkRestTest to make sure a LIMIT is added immediately after FORK, so the query becomes:

FROM semantic_text
| KEEP semantic_text_field
| sort semantic_text_field asc;
| FORK (WHERE true) (WHERE true)
| LIMIT 300
| WHERE _fork == \"fork1\"
| DROP _fork 

At the moment we don't push filters that are present after FORK into FORK branches (we should), so the implicit LIMIT we add at the end of each ES|QL query does not get to be pushed down into FORK branches.
Adding a LIMIT after FORK, ensured our optimizations will push the LIMIT into FORK branches.
I also had to adjust our existing optimizations, to recognize that when we have an unbounded SORT in the FORK branches, and we have a LIMIT (or a SORT + LIMIT) following FORK, we should still do a push down into the FORK branches, even if another pipeline breaker is present in the FORK branch.

[ioanatia]

I removed this check here, because we already use randomBoolean in addRandomPragma

[elasticsearchmachine]

Pinging @elastic/es-search-relevance (Team:Search Relevance)

[carlosdelest]

LGTM, thanks for explaining the problem so thoroughly 👍