[Saved Objects] Add ability to query during saved object migrations

[FrankHassanabad]

Parent meta ticket #109169

Describe the feature:
During Kibana migrations in some cases we need to be able to conduct an additional query to get children or other saved objects to migrate or to fix the saved object references array.

The main use case is the exception-list and exception-list-agnostic containers which both have children but those children are not wired up to the main container's saved object references. Right now we use an ID called list_id which is a non saved object. This doesn't hamper or hurt anything if the UUID's are re-generated but this can cause duplicate list and list items when we begin sharing between spaces if the user is importing the same exception list and exception list items to other spaces.

Second use case is that we have saved objects such as the "siem-detection-engine-rule-actions" which is a saved object that has a reference back to the original alert and was put into place by developers a long time ago before the maturity of notifyWhen and throttle options. For us to move away from that, we need a type of "join" where we can query the alerting from it when we migrate.

Describe a specific use case for the feature:
As a platform engineer, when I copy or import the same exception list and its exception list items to two different spaces and then share both of the lists, they should show as completely unique.

As a platform engineer, when I click on "relationships" for the saved objects of an exception list I would expect the exception list to show all of the exception list items as children.

[elasticmachine]

Pinging @elastic/security-detections-response (Team:Detections and Resp)

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[rudolf]

We explored this in #34996 (comment) which also lists some of the complexities/pitfalls.

[pgayvallet]

This seems very similar to #34996.

Querying (against the target index) during the migration is not really doable, as all the objects will not be present when migrating a given one, which is why the approach we thought about was to be able to generate a pre-migration context from the source index before performing the migration, to allow migration function to collect and use state from the source index.

The issue is currently closed because the implications are complex (e.g as you query against the source index, you can't know for sure the shape/version of the objects)

[yctercero]

Closing this ticket as we're not going to be moving in this direction after meeting with core.

[yctercero]

Reopening as it's still something that is desired and worth figuring out if it will be possible.

[lukeelmers]

@yctercero Did we determine whether #34996 would be sufficient for your use case? Asking because that proposal has fewer open questions around it and is more feasible from core's perspective. (Apologies, I can't remember where we landed on that right now).