Collection drops happen in two-steps:

1. Rename the collection to special name that encodes the optime of the drop. This phase is replicated.
2. When the optime becomes majority committed, asynchronously notify the storage engine the collection can be removed.

This process gives a guarantee that the storage engine can safely throw away collection without fear of needing to get it back later.

Because the collection drop is "behind the replica set commit point" and we currently only plan to allow reads at the commit point, it is safe to not timestamp the write that removes the key/value pair from the storage engine's catalog. Doing so would be convenient to eliminate the risk of assigning a stale ghost timestamp.

Timestamps for this drop can be assigned in two code paths:

1. When the reaper processes the final step of dropping a collection.
2. When `KVStorageEngine::dropDatabase` drops the remaining collections that the reaper has yet to get to.

The latter is the more substantial change, particularly to the documentation.