Before distinct multiplanning was implemented, we would not multiplan in case of distinct scan (and wouldn't need to consider SBE compatibility). This meant that in the fallback case, we were always eligible for SBE (i.e. no distinct scan was possible).

Now, since we are considering for multiplanning both distinct scan and non-distinct scan candidates, and since DISTINCT_SCAN is not SBE-compatible, we have to mark the query as ineligible for SBE even before we know if we can even get a distinct scan. This marks a large set of queries as ineligible for SBE (e.g. even a simple $group with only an _id field is eligible for a distinct scan).

As a stop gap measure to restore previous behavior, we should change this condition to reset the distinct() property on CanonicalQuery when no indexes eligible for distinct scan conversion are present (and not just when there are no indexes). This should restore the previous behavior of generating SBE plans when we can't produce DistinctScans (though we may now sometimes get an index scan even though a distinct scan is possible; in this case, we won't use SBE).

We should be able to reuse this function for that check.