The current mechanism used by ReplSetTest and ShardingTest makes brittle assumptions about the structure of PKI used in jstests/ssl which in turn makes doing new and interesting things with PKI (such as SERVER-74999) unnecessarily difficult to test.

Possible improvements:

1. Create legacy shell only commands to alter the internal state of the client's TLS parameters (e.g. Change the configured tlsCertificateKeyFile, or allowInvalidHostnames, etc...)  This allows more complex tests to set up an appropriate testing environment.
   • Pro: This should be fairly simple to implement and only adds complexity to the legacy shell, which is no longer used in production.
   • Con: This is ultimately a band-aid on a larger, and more complex problem.
2. Use subprocess instances of mongo legacy shell with callbacks to customize the configuration from the calling test.
   • Pro: This isolates the authentication state used for management from the authentication state used for the actual test.
   • Con: This is likely to impact testing performance since additional subprocess shells must be spawned. 
   • Con: This is likely to take much more time to implement as callbacks can no longer share variable scope with the test.
   • Pro: Management commands no longer share (pollute) the test's variable scope)