There are multiple projects in 3.6 that result in secondaries trying to send a message to the node it believes to be primary. We are using the RemoteCommandTargeter interface to determine who the current primary is and thus where to send the command. The only available implementation of the RemoteCommandTargeter interface, however, achieves this using the ReplicaSetMonitor. Starting a replica set monitor to monitor a node's own set is not ideal for many reasons.
For one it requires spinning up threads and doing work over the network, which is completely redundant of work the ReplicationCoordinator is already donig.
For two, the view of the replica set from the ReplicaSetMonitor is likely to almost always be more stale than the view in the ReplicationCoordinator.
Finally, spinning up a ReplicaSetMonitor is going to cause lots of log messages associated with it to start appearing. I'm worried about users getting confused or upset when they see a node sending messages to itself over the network for the purposes of monitoring its own state.

Instead of using the ReplicaSetMonitor for this, we should add a new implementation of RemoteCommandTargeter that just asks the ReplicationCoordinator to tell it a node that matches the given read preference, and we should use this new targeter any time we need to target nodes within our own replica set.