[Alerting] Smarter retry interval for ES Connectivity errors

[ymao1]

When an alerting execution encounters an error, it reschedules itself for the next schedule interval. With this PR Kibana Core introduced a specific error type EsUnavailableError for transient ES connectivity errors. We should look for these errors in the alerting task runner and consider handling them slightly differently than other errors based on the configured schedule interval of a rule. If a rule is scheduled to run every 24 hours and it encounters a transient connectivity issue, it would make more sense to schedule its retry for a shorter interval, like 5 minutes instead of waiting another 24 hours for execution.

Towards #119650

[elasticmachine]

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

[pmuellr]

So we really just need to pick a number, right? 5 minutes feels about right to me. If the interval is < 5m, let it run on it's existing schedule. Otherwise retry in 5m.

It probably doesn't make sense to bake this kind of logic into task manager (yet anyway), right? Especially since rules do kind of wacky scheduling anyway ... and not sure TM could recognize ES connectivity errors.

Just thinking about eventual "cron" scheduling. I think this will work there as well. We'll have to come up with a way of taking whatever "cron" schedule we have, and the current time, and have it tell us the "next" time. So we'll have the next interval, and can make the same calculation there ...