Ensure broadcast when remaining peer becomes unavailable

[dirkmc]

Fixes #259

[dirkmc]

The test failure (panic) in CI might be related - we're now telling it to broadcast when the last peer in a session disconnects, so that might be having some after-effects. I will dig in.

[Stebalien]

Is there any way to reduce the state a bit? Ideally, we'd:

1. Process updates.
2. Look at the current state and react to it.

(not blocking, I'm just trying to simplify bitswap a bit)

[dirkmc]

Yeah I agree, there's a lot going on in this class. I've tried to break out bits of it into different classes (eg peerAvailabilityManager) but it still feels too complicated to keep track of everything.

Maybe we can break out the DONT_HAVE tracking into two classes:

• track consecutive DONT_HAVEs (and eject peers that get too many in a row)
• track want exhaustion (every peer sent a DONT_HAVE for a particular want)

[Stebalien]

I'm more concerned about threading updates around than having a lot of state. Really, having related state all in one place makes it easier for me to keep track of it.

It's not really an issue with this patch, just something that's creeping up on us.

[dirkmc]

It turns out the problem was with the timing of a test that would verify the session will call FindProviders() after being disconnected from a peer that had the blocks. I changed the logic of the tests to not rely on timing.

While I was doing so I realized that when the session receives "exhausted" wants (wants for whom all peers have sent a DONT_HAVE) it would broadcast a request for all pending wants, instead of just those specific exhausted wants. So I also fixed that issue.