When testing sharding commands in the fsm concurrency suite, the high volume of traffic on the distributed lock often causes the dropCollection command to return a LockBusy error simply because other sharding commands such as moveChunk, mergeChunks, and splitChunk are still running and/or contending on the distributed lock.

Having the timeout set to a much higher value (but still lower than the lock takeover timeout) allows for:
1) test readability and simplicity: a failure in the test corresponds to an actual failure.
2) exercising the server's retry logic rather than the test's.