Currently the shard registry is returning a sorted vector of shard IDs:

• ShardRegistry::getAllShardIds
• ShardRegistry::getAllShardIdsNoReload

Even though this is not necessary, many logics in the codebase relies on these two functions and uses the sorted vector of shard IDs. The consequence is that several of our tests are built on the wrong assumption that there is an order of importance among the shards. For instance:

• We assume that chunks of a new collection will be spread on shard according to their IDs ascending lexical order.
• We assume that the primary shard of a new database will be the first shard in ascending lexical order with less data on it.
• We assume that almost all the broadcast communications in the cluster will be carried on in a round robin fashion according to the shard IDs ascending lexical order.

In order to improve horizontal scalability of the cluster it is important that our internal algorithms treats all the shards in the same way and do not assign any specific order of importance to the shards based on their names.