I initially opened this ticket because our tests were flaky, as the drivers currently hardcode a connection timeout of 1 second, which may be less than what it takes a mongocryptd process to spawn up, and which in turn led to flaky tests on our side.

However, after thinking about it a bit more, I think we want to spawn mongocryptd manually either way, as the current situation also has other downsides (like blindly connecting to whatever is listening on port 27020 or e.g. mismatching mongocryptd versions).

I would suggest that we spawn mongocryptd ourselves when connecting using FLE, with at most 1 mongocryptd process per mongosh process. We could store the pidfile (and, on UNIX, the UNIX socket file) next to the logfiles. On Windows, we could use --port 0 to listen on an arbitrary port, which we can extract from the structured log we receive on the mongocryptd process’es stderr. In either case, we can wait for log messages from stderr to make sure that the child process is actually listening by the time we’re connecting.