Do not merge patterns with exclusions

[idegtiarenko]

This change prevents merging unions into a single pattern if any of them contain exclusion.

For example with the following setup

        addIndex("data-ll");
        addIndex("data-rr");
        addView("data-l", "FROM index-l");
        addView("data-r", "FROM index-r");

A query FROM -*l,data-*
was resolved as FROM index-l,index-r,-*l,data-*
where index-l was excluded by -*l.

Now it is correctly resolved as FROM (FROM index-l,index-r),(FROM -*l,data-*) containing the scope of -*l exclusion.

[elasticsearchmachine]

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

[idegtiarenko]

I think we could still merge patterns if exclusion is only present in the first pattern, but not in the second one. Not sure if it could cause other issues? Maybe with deterministic execution?

@n1v0lg maybe you have an opinion on this?

[craigtaverner]

LGTM - Although I think we can also consider stripping leading exclusions in general, as a separate refinement (but that will require changing this test).

[idegtiarenko]

This highlights one change in behavior.

FROM logs* matches both logs2 index and logs1 view that effectively points to logs2 index.

With exclusion the patterns are kept separate in 2 subqueries. This would effectively read from logs2 twice.

If we remove the exclusion, the pattern would be coalesced to logs2,logs* since we no longer need to scope exclusion. As a result logs2 would be resolved and queried only once.

[idegtiarenko]

I think it is intended to query index twice if it is referenced directly by a pattern and by a view, but I do not think that we can do that reliably with patterns.
Maybe that could be achieved if we never merge relations.