This refactoring would help reducing the impact of the reliability versus efficiency dilemma. That is, that for coarse grained operations a small timeout could prevent ooniprobe from bootstrapping (as discussed in https://github.com/ooni/probe/issues/2544), while, conversely, a large timeout is more reliable but leads to reduced efficiency in the sense that ooniprobe spends more time waiting for timeouts to happen.
The changes in https://github.com/ooni/probe-cli/pull/1351 probably illustrate this dilemma reasonably. In there, I had to create an overall 45 seconds timeout for IP lookups because we have 7 resolvers plus the system resolver. This means that, in the worst case, we expect 7*4 = 28 seconds of timeout before eventually using the system resolver. The rest of the timeout accounts for operations happening after the DNS lookup has succeeded.
This issue is the follow up of https://github.com/ooni/probe/issues/2544 and https://github.com/ooni/probe/issues/2545. We should decompose the iplookup operation into smaller, overlapped operations with fine grained timeouts.
This refactoring would help reducing the impact of the reliability versus efficiency dilemma. That is, that for coarse grained operations a small timeout could prevent ooniprobe from bootstrapping (as discussed in https://github.com/ooni/probe/issues/2544), while, conversely, a large timeout is more reliable but leads to reduced efficiency in the sense that ooniprobe spends more time waiting for timeouts to happen.
The changes in https://github.com/ooni/probe-cli/pull/1351 probably illustrate this dilemma reasonably. In there, I had to create an overall 45 seconds timeout for IP lookups because we have 7 resolvers plus the system resolver. This means that, in the worst case, we expect 7*4 = 28 seconds of timeout before eventually using the system resolver. The rest of the timeout accounts for operations happening after the DNS lookup has succeeded.