fix want gauge calculation

[dirkmc]

Fixes #413

A slight performance degradation but it's not too bad:

#395

$ go test ./internal/peermanager -run xyz -v -bench . -benchtime 5s
cpu.out
goos: darwin
goarch: amd64
pkg: github.com/ipfs/go-bitswap/internal/peermanager
BenchmarkPeerManager
BenchmarkPeerManager-8   	  182610	     33038 ns/op

This branch:

$ go test ./internal/peermanager -run xyz -v -bench . -benchtime 5s
goos: darwin
goarch: amd64
pkg: github.com/ipfs/go-bitswap/internal/peermanager
BenchmarkPeerManager
BenchmarkPeerManager-8   	  169858	     35684 ns/op

[dirkmc]

The test/race failure is a red herring 🐠 - I've fixed it in the refactor branch

[Stebalien]

I'm slightly concerned about performance here on cancellation here. It's probably fine but I wouldn't trust a microbenchmark unless we're testing sessions with hundreds of peers.

Alternatively, we can probably go back to a single want gauge. We added a second one to fix #333, but the real issue was that we weren't tracking the number of items we wanted, we were tracking the number of outstanding want requests sent. Simply tracking the total number of wanted items (have and otherwise) would allow os to vastly simplify all this logic.

[dirkmc]

The benchmark tests with 500 peers. Maybe we can try running on staging and see how it fares?

I'm not sure if it actually would be simpler to track the total number of wants - we'd still need to make sure we're not double counting across peers and across want-have / want-block / broadcast wants.

[Stebalien]

Ah, ok. Then it's probably fine.

I'm not sure if it actually would be simpler to track the total number of wants - we'd still need to make sure we're not double counting across peers and across want-have / want-block / broadcast wants.

We'd just track, "is wanted" for each wanted CID, right? That is, it's "wanted" if len(pwm.wantPeers[c]) > 0 || pwm.broadcastWants.Has(c).

[dirkmc]

Ah yes, you're right that would be simpler