Enable merging saved objects with the same origin

[jportner]

This issue describes a topic of shared responsibility between the Platform Security and Core teams, however it feels like a bit more of a Platform Security responsibility due to the Spaces aspect.

Background

When we introduced Spaces, "isolated" saved objects did not need to have a globally unique ID -- the object ID only had to be unique within a single space. This inadvertently introduced the behavior that objects that are copied to different spaces retain the same "origin" because they had the same ID. When copying or importing an object, you would always overwrite a conflicting object that had the same origin. For example, a user could take the following steps:

1. Create an object in space A
2. Copy the object from space A to space B
3. Export the object from space B and import it into space C
4. Make some changes to the object in space C
5. Copy the object back to space A and space B

After all of this, you'd be left with three identical objects in spaces A, B, and C.

When we introduced shareable and share-capable saved objects, we formalized this concept with a new saved object field, originId. These shareable and share-capable objects must have globally unique IDs, so if they are imported/copied to a different space, the new object's ID is regenerated -- but the object's origin (its old ID) is still retained in the originId field to preserve the old import/copy behavior.

Starting in the 8.2 release, data views are shareable, and more existing object types will be made shareable in the near future (#128907). However, we identified a need to implement a restriction so that users cannot share an object to a space if another object with that origin already exists in that space (#127054).

This restriction will introduce friction in the "assign to spaces" UX (sharing saved objects UX), but for good reason -- to protect users from getting Kibana into a state where different URLs conflict with one another. However, the restriction will be presented at "assign time", and it won't be actionable at first. In the example above, if you want to change the space assignment for the object in space A, Kibana will prevent you from adding it to space B or space C, because the object had previously been copied there.

Describe the feature

To address this friction, we envision that users will want the ability to "merge" multiple objects with the same origin. This can be a complex undertaking:

• When changing an object's space assignment, you aren't just affecting that object -- you are affecting the entire graph of outbound references for that object. All of those references must be assigned to the same spaces, therefore the user may be prompted to "merge" multiple times for different objects.
• The attributes of any two objects may have diverged from when the copy was first made...
  • How exactly do we detect those differences -- should we attempt to do it in a generic fashion in Core, or should we attempt to allow different consumers to specify comparators?
  • How should we present any differences to users in a generic fashion and let them decide how to proceed?
• When you merge two objects, one of them will be deleted...
  • All inbound references to the deleted object would need to be updated to point to the other object (not just those in the reference graph that is being shared).
  • Legacy URL aliases that point to the deleted object would need to be updated to point to the other object too.
  • The resulting merged object would have to have a superset of the space assignments of both objects (to avoid broken references).

Describe a specific use case for the feature

1. When you attempt to change an object's assigned spaces, and Kibana tells you that you can't do that because an object with the same origin already exists in a given space, we could show a button to prompt you to merge the two objects
2. If we have a "unified" Saved Objects Management page in the future that shows objects across all spaces, we could prompt users to merge 2+ identical objects so they stay in sync

[elasticmachine]

Pinging @elastic/kibana-security (Team:Security)

[elasticmachine]

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