Investigate optimizations when version restriction represents low percentage of node population

[derekpierre]

During sampling when the version being restricted represents only a small percentage of the network eg. 8/20 nodes run a version that we are sampling for, then sampling can take a long time. In this case 8/20 nodes running 7.4.1 pre-release, and sampling 8 took ~30s. However, this is a bit of a special case during pre-release testing, but the investigation could lead to overall efficiency improvements nonetheless.

From Discord:

Porter typically connects to each node, gets the json data from the status endpoint - this is the common uptime check - and then if version is restricted, compares the version. This is a bit of a special case because 7.4.1 isn't a widespread version that nodes are running, so getting some number n <= 8 when only 8 / ~120 nodes are running the required version could take some time.

For example, if we want to get all 8 nodes running v7.4.1, the worst case is getting the final 8th node on the 120th node being connected to (i.e. the last node to check). That means that Porter had to connect to all 120 nodes before returning. Now, of course Porter actually does parallel connections using a thread pool, so there is some parallelism that helps to reduce the time - not that it couldn't be further improved of course.

That being said, if even 50% of the network was running 7.4.1, it's very likely the query would take much less time.