[ResponseOps][Alerting] ES Query rule should reflect actual cause of fieldcaps errors

[pmuellr]

See #175980 (comment)

In the case where the fieldcaps call run when an ES Query / KQL rule is run, and the fieldcaps call returns a 404, the error logged is

Executing Rule default:.es-query:{id} has resulted in Error: Data view with ID {id} no longer contains a time field

This is a bit misleading, because what actually happened was there were no indices matching the fieldcaps request. We should be more precise.

The referenced issue also notes that we have some "bad behavior" when a 502 is returned from fieldcaps. I suspect we'd see the same result. Something seems to be "eating" the errors out of the es call. Perhaps we can repro this with a jest integration test. We obviously like to see that we got a 502 response from the fieldcaps call as the reason for the rule failure.

[elasticmachine]

Pinging @elastic/response-ops (Team:ResponseOps)

[pmuellr]

I want to point out this comment from an SDH https://github.com/elastic/sdh-elasticsearch/issues/8571#issuecomment-2492013970:

it is possible for field_caps to return a 404, but its rare and requires index & shard movement to occur during the API call

So we'll want an indication from DV if it got a 404. We may want to retry these, no clear yet. May be rare enough that failing is fine.