EQL: consider applying tier filters also to field_caps

[luigidellaquila]

In some scenarios, the user could expect that if a query only involves data from a specific tier, it doesn't consider other tiers at all, not even for planning purposes.

This is not true today, eg. if a foo field is declared as keyword in the hot tier indices and as text in the frozen tier indices , even if the query has

"filter": {
    "term": { "_tier": "data_hot" }
  }

accessing that field in the query will still lead to conflicts, eg.

Cannot use field [foo] due to ambiguities being mapped as [2] incompatible types

This is due to the fact that field_caps does not take filters into consideration, and the planning is executed base on the mappings of all the indices.

This is by design, but sometimes it's confusing, so we could consider reviewing it or providing an option for a different default.

For completeness, changing this behavior could lead to errors on existing queries:

• suppose you have N indices idx1 ... idxN
• idx1 has a field called foo, other indices don't
• a query like

  GET /idx*/_eql/search
  {
    "query": "any where foo == 10 or bar == 20",
    "filter": {
      "term": { "_tier": "data_hot" }
    }
  }
  

  succeeds as long as idx1 is on the hot tier
• as soon as idx1 is moved to the frozen tier, with current defaults the query keeps working fine; if we change the defaults, completely ignoring the frozen tier, the query will start failing.

[elasticsearchmachine]

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