In getDistinctNodeIndex(), we currently only look at the projection when choosing an index for a hand-crafted distinct scan. We should also take into account the shard key if shard filtering is requested. For an example, consider distinct("notShardKey") with the indexes notShardKey_1 and notShardKey_1_shardKey_1. The current heuristic picks the first index, forcing us to redundantly fetch. Note also that for $group queries, the shard key and the projection might not have any common fields, and we should only consider the query covered if it can cover both of them.