The test  perform:

• createCollection(nss)
• createIndex(nss)

After a first check, the collection runs $listCatalog Collectionless (against the adminDb) and later ensures that every entry (local catalog of shard X) has a fixed expected number of indexes.

This test always works on any suite because:

• in case of replica-set we have one entry per nss
• in case of {create...} on a sharded cluster we have 1 chunk per nss (collection always on the primary)
• in case on "sharded_jscore_passthough" we shard using hashed shard keys, having one chunk per shard

Until now the createIndex always targetted either the primary or every shard, ensuring to have the expected number of indexes on every non-empty entry

After the introduction of the "unsplittable_collections_on_any_shard_jscore_passthrough" we now create a the collection on a random shard using the createUnsplittableCollection test command. In case the collection is not created on primary we have a situation where:

• the primary shard only has {_id } index
• the second shard has { _id } + the created indexes

This leads the test to fail since the number of expected indexes on the first shard does not match. 
The goal of this ticket is to:

• evaluate whether to ban the test from the suite (not advised)
• rewrite the checkEntries function to ensure exactly 1 entry has the number of expected indexes