Prevent multiple objects of the same origin in a space

[jportner]

Background

If a saved object is shareable, when it is imported or copied into another space its ID changes but it retains a record of its "origin". This is necessary to preserve legacy import/copy behavior, which allows users to create at most one copy of an object in a space, and allows users to overwrite the object in the future (this has many applications, including but not limited to: backups, using separate spaces for staging/production, and using separate clusters for staging/production).

For example, if a visualization was created in the Default space and then copied to Another space, you would have these two objects:

┌───────────────────────┐  ┌───────────────────────┐
│type: 'viz'            │  │type: 'viz'            │
│id: '123'              │  │id: '456'              │
│namespaces: ['default']│  │namespaces: ['another']│
│                       │  │originId: '123'        │
└───────────────────────┘  └───────────────────────┘

If the user had these two visualizations before upgrading to Kibana 8.0, then upon upgrading, they would also have a legacy URL alias in Another space for viz:123 that points to viz:456.

┌───────────────────────┐  ┌───────────────────────┐  ┌────────────────────────┐
│type: 'viz'            │  │type: 'viz'            │  │type: 'legacy-url-alias'│
│id: '123'              │  │id: '456'              │  │id: 'another:viz:123'   │
│namespaces: ['default']│  │namespaces: ['another']│  │targetId: '456'         │
│                       │  │originId: '123'        │  │...                     │
└───────────────────────┘  └───────────────────────┘  └────────────────────────┘

Currently, an object can be shared to a space where another object of the same origin exists. In the example above, viz:123 can be shared to Another space even if it's otherwise identical to viz:456, which already exists there. If that happens, we prompt the user to disable the conflicting alias before proceeding -- we must do this to prevent a "legacy URL alias conflict" when the user tries to view a URL for viz:123 in Another space.

---

Enhancement

In #123550 we want to allow users to create new legacy URL aliases for objects when their IDs are changed on import so that weak links are preserved.

There are two sharing-related edge cases, we'll use the second example above:

1. If viz:123 is shared to Another space first, then the user imports/overwrites viz:456 and creates a new alias for the object's origin ID: accessing viz:123 in Another space will result in a legacy URL alias conflict.
2. If the user imports viz:456 into a Third space (becoming viz:789) and creates a new alias for the object's origin ID, then shares viz:123 to the Third space: the alias will have been removed, and any weak links that are supposed to point to viz:789 are actually pointing to a completely different object.

The ability to have multiple objects of the same origin in a space will be detrimental to users in this case, and we don't yet have any automated way to allow users to "merge" two similar objects. We could detect scenario (1) above at import time and return an error, but the error won't be actionable, it will only prevent the user from importing/copying.

The safest thing to do right now would be to prevent having multiple objects of the same origin in a space to begin with (when the user is first attempting to share in this manner).

In the future, we can provide users with an actionable UI to merge 2+ objects with the same origin, but that is a non-trivial thing to implement, so I opened a separate issue for it: #130311

[elasticmachine]

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