Import saved object does not prefer exact match when using overwrite=true

[jportner]

When importing or copying a saved object, conflict destination checking occurs based on the object's origin.
An existing object could have a matching origin without having the same object id.
The object's origin is its originId by default, or if that field is undefined, it is the object's id.

When multiple conflict destinations are found, the "exact match" should always be preferred if possible. This is demonstrated in our internal design documentation:

However, I found this not to always be the case. There is a bug in the logic that only exists when the overwrite=true option is enabled, where if there are 2+ destinations, the "exact match" destination is completely ignored.

• If there is one remaining destination ("inexact match"), that one will be overwritten instead.
• If there are 2+ remaining destinations, the user is presented with an "ambiguous_conflict" error and forced to choose one of the other destinations.

I confirmed this using my Sharing Saved Objects test plugin. In the example below, all four of the "Army Man" objects share an origin. I exported one and attempted to import it again, and I was presented with an ambiguous conflict error:

Note: this bug was introduced in #58139, and it technically exists as early as 7.10. However, the only way to get Kibana into a state where multiple objects in the same space share an origin is to share one from a space to another space. The only shareable objects pre-8.0 are ML jobs, and those cannot be imported or copied. So this bug doesn't impact any users yet, but we should fix it for the 8.0 release.

Edit: it is not possible to encounter this bug while copying saved objects, because we don't allow an object to be copied to a space where it already exists. E.g., you can't run into an "exact match" conflict when copying an object. So this bug only affects import.

[elasticmachine]

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