Current behavior

Currently, in order to implicitly shard collections on 'sharded' suites, the following test functions DB.prototype.createCollection, DB.prototype.getCollection, and DBCollection.prototype.drop are overridden on the implicitly_retry_on_migration_in_progress.js file so that, whenever a test calls one of these functions, a sharded collection is created under the hood.

Motivation

The problem with this approach is that many tests are excluded from 'sharded' suites because of a variety of reasons:

• Collections may exist when they're not expected. For example, the DBCollection.prototype.drop override recreates the collection instead of just dropping it.
• It's not possible to create a collection with non-default paramters after instantiating the collection object. This is because the instantiation of the collection object implicitly shards the collection, therefore, the test will fail if a succeeding operation tries to create a collection with different parameters.

Therefore, we'll significantly increate the test coverage over sharded collections with non-default parameters.

Goals

The goals of this ticket are:

• Override the runCommand to create a sharded collection if the collection doesn't exist yet whenever:
  • a command that must implicitly create a collection is called.
  • a `create` command is called.
• Remove the overriding of the following DB methods:
  • DB.prototype.createCollection, DB.prototype.getCollection, and DBCollection.prototype.drop
• Improve the test coverage around sharded collections by removing the tags `assumes_no_implicit_collection_creation_after_drop` and `assumes_no_implicit_collection_creation_on_get_collection`.