This ticket makes it such that attempting to drop collections under the admin or config database through mongos will now throw an error. Attempting to call dropDatabase on admin or config will similarly throw an error. It is still possible to drop these collections when connecting directly to the config server.

Original Description:

_configsvrDropCollection calls lockWithSessionID() which sets the readSource to be kMajorityCommitted and all the following commands from _configsvrDropCollection would erroneously keep using kMajorityCommitted as the readSource.

Here is what happened in BF-9590:
1. The config primary server got _configsvrDropCollection command.
2. The distributed lock manager ran lockWithSessionID which triggered a majority read, so the readSource of the WiredTigerRecoveryUnit was set to 'majority'.
3. There was another thread which just finished adding an index to the collection "admin.mod1"
4. _configsvrDropCollection finally called dropCollection which did a check whether the numbers of indexes on disk and in memory were equal. Since the readSource was still "majority", we read the on-disk catalog with "majority" timestamp when the change to index catalog was not made yet. But the in-memory index catalog has the new index.

Update:
_configsvrDropCollection() finally called dropCollection() because the collection is in admin database whose primary shard is the config server itself.