explodeForSort can produce incorrect query plan

function assertSortOrderWithCollationIndexBF17891() { const coll = db.bf17891; coll.drop(); assert .commandWorked(db.createCollection(coll.getName()));   // Create an index with a non-simple collation. assert .commandWorked( coll.createIndex({a: 1 , b: 1 }, {collation: {locale: "en_US" , strength: 1 }}));   // Insert some documents into the collection. The value of 'a' is the same non-string value for // each document, while 'b' is a string. assert .commandWorked( coll.insert([{a: 0 , b: "ccc" }, {a: 0 , b: "ddd" }, {a: 0 , b: "CCC" }, {a: 0 , b: "DDD" }]));   // Run a point-query on the first field of the compound index with a sort on the second field. const indexSortedResults = coll.find({a: 0 }, {_id: 0 }).sort({b: 1 }).toArray();   // Repeat the query but this time force a COLLSCAN. const collScanSortedResults = coll.find({a: 0 }, {_id: 0 }).sort({b: 1 }).hint({$natural: 1 }).toArray();   // Print out the explain results for this query. It will be observed that the plan is a // SORT_MERGE-IXSCAN using the {a: 1, b: 1} index, despite the fact that this index has a // non-simple collation. The {a: 1, b: 1} index is eligible to answer the query because the // predicate 'a' is a non-string value. We then run through some checks to see whether we can // avoid performing an in-memory sort, eventually calling QueryPlannerAnalysis::explodeForSort. // But this method fails to notice that the index's collation should make it ineligible to // provide a sort for this query, and so we end up producing a SORT_MERGE plan that will // incorrectly sort the output according to the collation. printjson(coll.find({a: 0 }).sort({b: 1 }).explain());   // The documents should be returned in ascending order, but instead are sorted according to the // case-insensitive index. The COLLSCAN produces the correct ordering of results. assert .docEq(indexSortedResults, collScanSortedResults); }