This ticket fixes a fuzzer BF.

To summarize the issue:
$setWindowFields is outputting one doc differently, which is generating different keys for $group's hashmap of keys to accumulators. Essentially one doc/key has the string before the time and in the other run, it's the opposite.With wildcard index, setWindowFields produces:

{_id: 9, obj: {obj: {obj: {obj: {str: ""}}, date: 2012-10-17T20:46:22.000Z}}}
without wildcard index, setWindowField produces:

{_id: 9, obj: {obj: {date: 2012-10-17T20:46:22.000Z, obj: {obj:

}}}}

TLDR setWindowField is producing incorrect result without wildcard index, if it was the correct form/order, it would show that it's already in $group's hashmap and thus without wildcard wouldn't be outputting an extra doc from the $group stage/in the results.The reason why the key is wrong, is because during the non wildcard run, _executableOutputs is returns the wrong order when we iterate it in $setWindowFields doGetNext after the first doc is processed. In other words, the order of _executableOutputs is correct for the first doc in the run, but after that it flips for the rest of the docs. If it didn't flip at all, on processing the second doc we would see that the key already existed in the hash map and wouldnt be passing it off to $group again.

The reason the order flips is that std::unordered_map is ofc not ordered, but the reason we're see a bug now is generally (but not always) implementations std::unordered_map will happen to have a deterministic order based on the keys and their insert order. The fuzzer created a case where when ran many many times, nondeterministic ordering was triggered.

The fix is to switch to an ordered map.