[Response Ops][Alerting] Optimize alerting task runner for persistent (non-lifecycle rule types)

[doakalexi]

Resolves #148573

Summary

To help prepare for the framework to handle persistent (non-lifecycle rule types) that do not need the auto-recovery functionality performed by the framework, we added a flag for the rule type so they can opt in or out

Checklist

• Unit or functional tests were updated or added to match the most common scenarios

To verify

• Create a rule and verify that it is working as expected.
• Set autoRecoverAlerts: true for a rule type and create a rule using that rule type. Verify that the rule does not recover.

[elasticmachine]

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

[ymao1]

Can we add a functional test for a rule type that sets autoRecoverAlerts to false?

[doakalexi]

Can we add a functional test for a rule type that sets autoRecoverAlerts to false?

Resolved in this commit 2a2be5b

[ymao1]

LGTM! Left one comment about maybe checking for autoRecover in a different spot.

[ymao1]

Looking at this again, we could probably short circuit this logic even more by adding a check before processAlerts:

if (!autoRecoverAlerts) {
  logger.debug(`Set autoRecoverAlerts to true on rule type to get access to recovered alerts.`);
  return [];
}

WDYT?

[doakalexi]

Sure I can do that!

[doakalexi]

Resolved in this commit 5306a12

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 5fee880

Metrics [docs]

Unknown metric groups

API count

id	before	after	diff
alerting	465	466	+1

History

• 💛 Build #101546 was flaky 2a2be5b
• 💔 Build #101424 failed 171b523
• 💛 Build #101075 was flaky d3cbb3e
• 💔 Build #101027 failed b1811c4
• 💔 Build #100850 failed 93541e4
• 💔 Build #100811 failed ebcfb7f

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream