[alerting]: research generic way of handling background tasks like requests

[pmuellr]

Most Kibana plugins use platform-y app-architecty-y ways of accessing things like ES. Eg, http request handlers are automagically scoped to the user that made the request, in terms of ES, SO access, etc. There's some NP "context" stuff to deal with this.

Alerting and actions have a problem though - they run things in the background, not scoped to an http request, but to an API key bound to the alert/action. We've already handled existing cases like callCluster, internally, but we recently got a request for adding support for UISettings (and/or it's NP equivalent) in alert executors: #55052

So, it's easy to add one-off things like UISettiings support to alert/action executors, as another property an alert/action function can use, the question is whether there is a more general need for more support for similar services, and how we can accommodate that. Eg, what happens when we need 10 more of these user-scoped services?

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[pmuellr]

some related discussion in issue #39430

[ymao1]

Closing in favor of #56773