Ensure that the balancer is using Broflake in the way that Broflake ought to be used

[noahlevenson]

Once a transport starts failing, the balancer won't use it again unless all the other transports are failing.

This makes it difficult (impossible?) to measure whether Broflake is working or not, since Broflake, as a p2p system subject to network churn, is expected to fail intermittently all the time.

I suspect what will happen in most cases is that the balancer will try to dial using Broflake for the first time -- the dial will fail, because the Broflake client hasn't yet acquired a peer connection -- and the balancer will never attempt to use Broflake again.

[noahlevenson]

Via @oxtoacart on Slack:

Balancer actually has a facility for dealing with this, namely probing. Last I knew, it was globally disabled, but we should consider enabling it.

[oxtoacart]

Here's another solution:

Balancer relies on the dialer to tell it whether the dialer is succeeding. If the Broflake library could expose something that gives an indication of whether or not it's succeeding, the Broflake dialer impl could just return that to the balancer.

So for example, if broflake doesn't have any peers, it could return false. Or if it has a peer, but connectivity to that peer seems to be compromised, return false. But if we've gotten a new peer that appears to work or we at least don't know whether or not it works, we could return true.

[noahlevenson]

Changing the title here to reflect the fact that we really need to fix this (or at least feel confident that it's working well enough) for the soft launch.

Since the balancer can't dial with Broflake until Broflake has acquired a peer connection, and Broflake can't acquire a peer connection unless it can pierce the NAT, this issue depends on #163. Once I get through that work, I'll come back here.