GitLab

@jbenet @whyrusleeping

With these notifications, bitswap can reclaim all resources
for any outstanding work for a peer.

cc @briantigerchow @whyrusleeping

The area above the lock was getting big. Moving this up to avoid
mistakes down the road.

@whyrusleeping

Before, the engine worker would pop a task and block on send to the
bitswap worker even if the bitswap worker wasn't to receive. Since the
task could have been invalidated during this blocking send, a small
number of stale (already acquired) blocks would be send to partners.

Now, tasks are only popped off of the queue when bitswap is ready to
send them over the wire. This is accomplished by removing the
outboxChanBuffer and implementing a two-phase communication sequence.

	refactor: peerRequestQueue

	it's a mistake to make one queue to fit all. Go's lack of algebraic
	types turns a generalized queue into a monstrosity of type
	checking/casting. Better to have individual queues for individual
	purposes.

	Conflicts:
		exchange/bitswap/decision/bench_test.go
		exchange/bitswap/decision/tasks/task_queue.go

	fix(bitswap.decision.PRQ): if peers match, always return result of pri comparison

	fix(bitswap.decision.Engine): push to the queue before notifying

	TOCTOU bug

	1. client notifies
	2. worker checks (finds nil)
	3. worker sleeps
	3. client pushes (worker missed the update)

	test(PQ): improve documentation and add test

	test(bitswap.decision.Engine): handling received messages

	License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

License: MIT
Signed-off-by: Brian Tiger Chow <brian@perfmode.com>

Conflicts:
	exchange/bitswap/decision/taskqueue.go

mitigated adding our own addresses where received
from peers

see #573

Bitswap doesn't usually care about dialing. the underlying
network adapter can make sure of that.

@jbenet @whyrusleeping

This bug (missing return) could tie up the client worker and cause
operations to come to a halt.