feat(x): parallelize smartdialer testing when given multiple test domains

[ohnorobo]

We don't parallelize the testing on multiple test domains for the smartdialer, which can be slow if some of the domains take a longer time.

This adds another layer of parallelization for the test domains. (on top of using racetest for the strategies)

Some example testing output with a real config: https://docs.google.com/document/d/1kS7aeEe4UrXabOskd2B0QzR3QzmjDj26QabXnpeJW7I/edit?resourcekey=0-N2f-VSYcs1rBx3hG6s38OA&tab=t.0

[fortuna]

The way it works is that once we find a strategy that works for the first domain, we use the same for the other domains. Failed strategies don't get tested on other domains.

We need to limit the number of in-flight requests and how fast we send them.
The most efficient way to find a strategy is to go over the strategies first, before going over the domains.
By going over domains in parallel, you are wasting requests that could be used to find strategies instead. You are also wasting requests by testing strategies that don't work multiple times.

If you are achieving more efficiency, that's because you are parallelizing more, but you could as well parallelize the strategy finding instead.

The current design is intentional. Let's revert the change.

[ohnorobo]

The way it works is that once we find a strategy that works for the first domain, we use the same for the other domains. Failed strategies don't get tested on other domains.

We need to limit the number of in-flight requests and how fast we send them. The most efficient way to find a strategy is to go over the strategies first, before going over the domains. By going over domains in parallel, you are wasting requests that could be used to find strategies instead. You are also wasting requests by testing strategies that don't work multiple times.

If you are achieving more efficiency, that's because you are parallelizing more, but you could as well parallelize the strategy finding instead.

The current design is intentional. Let's revert the change.

The strategy finding is already parallelized (with a slight delay) through raceTests. The issue is when a user is testing multiple domains

Here's a specific example of a behavior we're seeing (for more log details see "Issue" at this link)

Duration of various connection tests for different domains using single strategy.

• [a.com] duration=266.390166ms
• [b.com] duration=2.029349417s
• [c.com] duration=61.22375ms
• [d.com] duration=675.53425ms
• [e.com] duration=3.051602625s
• [f.com] duration=2.125787667s

total startup time = 8.209887875s

Since we're running these requests in series it ends up taking fully 8 seconds before we can initialize the smart dialer. I'm not married to any particular solution here, but 8 seconds does seem absurdly long. I think this startup time has also gotten slower after we added #496 since we're now pulling more data in the test.

[fortuna]

We had issues with the backend throttling, showing captcha because of too many quick requests, but since we are talking to different backends in parallel, this will probably be ok.

Thanks for the change and the extra context.