When attempting to perform an internal read, we typically use our pipeline-building API to create a pipeline and attach a cursor source here, which can be either a local cursor (when running on a replica set) or a cursor which we establish via a sharded network request (when running on a shard). However, there are certain cases where the namespace we are attempting to read from is shard-local - that is, the collection exists independently on each shard - and attempting to attach a cursor source ends up incorrectly issuing a request to the remote primary shard instead, because the sharding infrastructure reports the collection as being unsharded. This has lead us to create an increasing list of exceptions for different internal namespaces as each such use-case is encountered, and in other cases to use NamespaceString::isNamespaceAlwaysUnsharded as an imperfect approximation of a check for shard-local collections.

We should add a new helper method NamespaceString::isPerShardNamespace or isShardLocalNamespace so that we can easily determine whether a given namespace is expected to exist independently on each shard, or whether we must issue a remote request to access it.