Ability for alert / action types to define migrations

[mikecote]

In scenario they changed the parameters for their alert / action type.
In the scenario we added name to alert.

This will be needed once we support mappings for config, params, etc

[elasticmachine]

Pinging @elastic/kibana-stack-services (Team:Stack Services)

[mikecote]

Some additional comments in issue #66608

[mikecote]

Linking with #84907 as it could help us here.

[spong]

+1 here from the Security Detections side. It would be beneficial for us to be able to leverage dedicated SO migrations for Detection Rules (and not having to embed the migration within Alerting). A recent example here is in needing to find all Detection Rules that reference a set of Exception Lists, whose reference is currently being stored in the Rule's AlertParams and cannot be searched. We don't currently have a back reference on our Exception Lists, so one solution would be to move the Rule's Exception List reference from AlertParams to internal tags within an SO migration (or leverage the existing SO references array).

[mikecote]

Moving from 7.x - Candidates to 8.x - Candidates (Backlog) after the latest 7.x planning session.

[stacey-gammon]

@joshdover @ppisljar - This looks like another use case for Persistable State. This is an interesting one though because it appears that the registrar can define mappings on the saved object. I was hoping we could get away with just leveraging "migrateToLatest" functionality rather than the SO-required object mapping (of version to migrate function), but because of this use case, we may need to continue to support both.