Initial wantlist handling is racy

[Stebalien]

The race is as follows:

1. Start processing the "Connect" event.
2. Read the current broadcast wantlist in:
   

   go-bitswap/bitswap.go

   Lines 438 to 444 in 916de59

   	// Connected/Disconnected warns bitswap about peer connections.
   	func (bs *Bitswap) PeerConnected(p peer.ID) {
   	initialWants := bs.wm.CurrentBroadcastWants()
   	bs.pm.Connected(p, initialWants)
   	bs.engine.PeerConnected(p)
   	}

3. Add a new wantlist entry.
4. Start the peer's message handler:
   

   go-bitswap/peermanager/peermanager.go

   Lines 158 to 170 in 916de59

   	func (pm *PeerManager) startPeerHandler(p peer.ID, initialEntries []*wantlist.Entry) PeerQueue {
   	mq, ok := pm.peerQueues[p]
   	if ok {
   	mq.RefIncrement()
   	return nil
   	}
   	mq = pm.createPeerQueue(p)
   	pm.peerQueues[p] = mq
   	mq.Startup(pm.ctx, initialEntries)
   	return mq
   	}

In this last function, initialEntries will be missing the wantlist entry from step 3.

[hannahhoward]

I was specifically trying to avoid two way coupling between the WantManager and the PeerManager, since the WantManager already has a reference to the PeerManager to send messages.

If we're going this route, I'd like to avoid that -- perhaps through SetDelegate similar to the one on bitswap Network

[Stebalien]

What if we:

1. Lazily created message senders on demand.
2. Instead of notifying the PeerManager of new connections, notify the WantManager. The WantManager would then initiate the MessageSender by sending the initial wantlist to that peer.

[Stebalien]

I believe this can also cause us to not cancel a want for a block.