Problem

After the driver upgrade in TOOLS-4329, mongorestore has a coverage gap: the driver enables adaptive overload retry on Database.RunCommand only when both retryReads and retryWrites are true (mongo/database.go:198). If a user passes --retryWrites=false (which from Glean sleuthing I believ is somewhat common, but correct me if I'm wrong here), the driver silently disables adaptive retry on every RunCommand invocation.

Mongorestore index creation and oplog replay plus a few other paths would be affected. Under load-shedding, any of these calls encountering SystemOverloadedError would fail the whole restore for --retryWrites=false users, even though the operation is safely retryable.

Solution

1. Confirm that mongodump and mongoimport don't have this gap: (mongodump is pure reads gated on retryReads; mongoimport writes only via BulkWrite gated on retryWrites) so I think this should only affect restore but double check me.
2. Either emit startup warning when --retryWrites=false, or expose a flag to let users pass a number of adaptive retries through to SetMaxAdaptiveRetries on the client independent of retryWrites, which lets users opt into th overload retry even with retryWrites=false. Or, I guess, we could add an outer retry loop that inspects for SystemOverloadedError/RetryableError and retries. 

We could also just add this to the public docs for dump/import