Came out of CDRIVER-3057. We should think carefully about handling conflicts of multiple keys with duplicate key alt names or keys sharing a UUID with different sets of key alt names.

Copied from the code review:

In cases where two keys conflict (different sets of keyAltName), perhaps the
right thing to do is always favor the key document has the more recent
"updateDate".

Conflicts might not be that uncommon, if we're getting some keys from the cache.
Consider a user moving a key alt name from one document to another.

Server first starts with:

Unknown macro: { _id}

Unknown macro: { _id}

The key cache contains

Unknown macro: { _id}

Then the user "renames" the entries:

Unknown macro: { _id}

Unknown macro: { _id}

The key broker gets two entries:
keyAltName="a"
keyAltName="b"

The first entry is satisfied with a cached value:

Unknown macro: { _id}

And the second is satisfied with the conflicting:

Unknown macro: { _id}

So in that case we could deduplicate based on "updateDate". That's not perfect,
as it's not guaranteed to be monotonically increasing, but it would probably
handle many common cases.

I think we should leave this as follow-up work, under a ticket like "Gracefully
handle all key inconsistencies"

This could involve:

• handle conflicting duplicate entries by favoring "updateDate"
• failing that, invalidate any matching cache entries (i.e. mark as expired),
  and try fetching again (maybe just once)

If that sounds good to you, I can create a ticket.

Edit: I think there's even more to consider. Requests for keys in the key broker
should stay satisfied after deduplication.

Consider:
Key broker has two entries:
keyAltName="a"
keyAltName="b"

First entry is satisfied with:

Unknown macro: { _id}

Then, second entry is satisfied with
{_id: 2, keyAltNames: ["b", "c"], lastUpdated: 2 }

When we deduplicate after the second entry, we'd remove the first entry since
it's older and has a conflicting shared keyAltName. But the marking requested a
key using keyAltName="a". So removing that key broker entry would leave that
marking unsatisfied.

Sooo... it might be a little more subtle. If one of the key broker entries would
be left unsatisfied after deduplication, perhaps refetch it, or don't
deduplicate?