The TaskExecutor and NetworkInterface base classes define pure virtual methods for appending ConnectionPoolStats information. These methods are invoked on a few significant TaskExecutor instances in FTDC collection and for the "connPoolStats" command.

• https://github.com/10gen/mongo/blob/48f78f134a762b4b7293efe8fb1f7a4106d83807/src/mongo/db/commands/conn_pool_stats.cpp#L103-L127
• https://github.com/10gen/mongo/blob/48f78f134a762b4b7293efe8fb1f7a4106d83807/src/mongo/db/ftdc/ftdc_mongos.cpp#L69-L82

This presents a few issues. Firstly, since the list of executors that actually append these stats are hard-coded, newer ones are omitted from stat collection unless explicitly added. We can actually see that in these two examples, where the connPoolStats command records information about the RSM's connection pool but mongos' FTDC doesn't.

Secondly, with the introduction of the gRPC transport layer for egress networking, not all TaskExecutors/NetworkInterfaces even have access to ConnectionPools that they can record sensible statistics for. At the moment, gRPC-backed NetworkInterfaces will use different definitions for the same stats in order to implement this API. This is okay for now since those stats are only used in testing scenarios, but we should improve this in case we ever did want to include the search task executors in the list of those that reported connection statistics.

To address these issues, we should remove the ConnectionPoolStats-specific methods from TaskExecutor/NetworkInterface, and instead only have the generic BSON-appending appendStats. Instead, we should use a global stats collection manager (similar to EgressConnectionCloserManager) for aggregate connection pool stat tracking. We could consider expanding the scope of EgressConnectionCloserManager itself to do this, and rename it something more generic as part of that.