[alerting] allow rules to "reset" themselves when params change

[pmuellr]

Spawned from #110080 (comment):

Some initial thoughts (that will need validation): Increasing the [rule] threshold and this way causing the condition to stop being met is not a recovery. If you change the threshold, you have reset the rule.

Good insight that we've now seen in practice. Lots of questions:

• how does the alerting framework indicate the rule should be "reset"?
• what do we do with the existing active alerts?
• we probably need new event log events, and these should probably also consider the "reset" that occurs with enable/disable
• we could this today by just "nulling" the rule state (stored in the task document) during a rule update, but maybe this is something rules should opt into

[elasticmachine]

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

[gmmorris]

@arisonl feels like this is more of a product question than a technical one at this stage.
Would love to hear your thoughts about how this behaviour should be.

[pmuellr]

One thought on how this could be done would be too allow rule types to opt-in to a "reset on update" behavior. So we'd clear the task state / active instances if it was set "on".

We have an issue for connector I refer to as "hooks for create/update/delete" - #106724 - that would allow connector types to get a chance to "do things" during those client API calls. We could provide a similar capability for rules, and then that would provide a way for a rule type to "opt-in" for a more customized experience. Maybe only when some of the rule params change, the rule should "reset". This would likely require us to provide some kind of service API the ruletype could invoke in these hook callbacks, to indicate that it wants things reset (task state, alerts, etc). I've updated that issue to mention this "hook" capability may be useful for rules as well.