[APM] Investigate alternative Alerting API approach

[sorenlouv]

We have created an issue where we outline some requirements for the alerting API.

We were hoping to have this available in 7.10 but it's been moved to "Long Term".
Instead an alternative approach has been suggested for the short term (7.10). We should investigate whether this workaround is sufficient for our use cases (Service Maps alert indicators and Observability Landing Page).
Important: we should not jump through hoops to make the integration work (we've incurred too much tech debt and introduced too many bugs doing this in the past). Either the API is applicable to the use case or it's not.

[elasticmachine]

Pinging @elastic/apm-ui (Team:apm)

[ogupte]

I believe the workaround that has been suggested was similar to the approach I mentioned in my comment. It works by fetching the task state for each matching alert returned in the find call. In setups with few alerts configured, it will add a few requests to the page load. But what if we're trying to load a service map with 10, 20, or more services where each has an alert configured? Are we OK adding an x number of single requests to our initial page load?

From the alerting plugin context, it might be possible to obtain multiple alerts states in a single request, but it would require querying the task manager index filtered by job ids obtained in the initial find. This would result in the initial page load adding a constant 2 additional requests instead of the suggested 1 + x requests.