killop_drop_collection.js is a core test that checks that killOp might or might not successfully interrupt drop collection (because after some point, interrupting drop collection might leave the server in a inconsistent state).

Since PM-1965 drop collection has the forward progress until succeed property in sharded clusters, meaning that after the creation of the coordinator, unless there is some unrecoverable error (like for example, the collection cannot be dropped), the DDLCoordinator will continue it's execution even in the presence of interruptions or failures.

This causes the following scenario:

1. The test issues a drop collection in a sharding jscore passthrough suite, sending the _shardsvrDropCollection command to the primary shard
2. The primary shard manages to instantiate a coordinator
3. The test issues a killOp, successfully interrupting the _shardsvrDropCollection command when it is waiting for the coordinator to finish

Because of 2, the listCollections command issued by the test will race with the coordinator, making this check non-deterministic.

One solution could be that in sharded clusters, we should not expect the collection to exist even if the killOp command succeeded.