When scheduling a remote request which contains a maxTimeMS in NITL, a local timer is started on the sender side, and when it fires the request's promise will be filled with a MaxTimeMSExpired error. This error is local to the sender though, and so it lacks any context as to why the timeout occurred. When using maxTimeMS, the remote recipient of the request will also time out at roughly the same deadline, but the error response it returns to the sender may never be read, since the sender's local timer may have already fired.

We should ensure that when maxTimeMS is used, the recipient's timeout error response is read, if possible. This may entail extending the local timer deadline slightly to account for the network round trip time. Drivers account for this by subtracting an estimate for the network rtt from the maxTimeMS specified in the request document (https://github.com/mongodb/specifications/blob/426c7d765078425db24cada3554fc84cde1941e7/source/client-side-operations-timeout/client-side-operations-timeout.md#command-execution)

Completing this should help with diagnostics, as the reason for a requests timeout can be read from the sender's logs, rather than just the recipient's.