After SERVER-114809, if we detect conflicts in arrayness when inserting paths into the PathArrayness data structure, we will always take the conservative guarantee, i.e. become array. However, there are cases where can actually take the non-array guarantee.

If we are are building from the full set of indexes and we see a conflict in arrayness then we should tend to the non-array assumption. This is because multikeyness in indexes can only go in one direction (non-multikey to multikey) and thus if the same path shows up as multikey and non-multikey then we know that the non-multikey guarantee is more up-to-date.

If we are inserting a path due to an index catalog update from a document write operation, then we should take the multikey state over the non-multikey state.

In essence we want to change this code in PathArrayness::insertPath():

   maybeChild->second._isArray |= (multikeyPath.count(depth) > 0); 

to instead be:

if taking conservative approach:
     maybeChild->second._isArray &= (multikeyPath.count(depth) > 0); 
else:
     maybeChild->second._isArray |= (multikeyPath.count(depth) > 0); 

We should encode this as a boolean or enum and plumb it through from the call sites.