Investigate making "DBClientBase::findN" more tolerant regarding network connectivity issues during execution, i.e. investigate the possibility of a fresh TCP connection to resume the findN as opposed to simply asserting.

Most interprocess communications use this function to issue calls to another MongoD, this includes Sharding, Replication and initial syncing.

If we can make this function (or somewhere on this code path) more tolerant to errors than we reduce the impacts of a flaky network connection on clients.