do not send cancel message to peer that sent block

[gammazero]

The serving peer cleans the client's wantlint after serving the block, making sending CANCEL to the serving peer redundant. So, exclude the serving peer when sending cancels after receiving a block.

Closes #694

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 60.52%. Comparing base (b7d0d20) to head (87c8c91).
Report is 1 commits behind head on main.

@@            Coverage Diff             @@
##             main     #784      +/-   ##
==========================================
+ Coverage   60.50%   60.52%   +0.02%     
==========================================
  Files         245      245              
  Lines       31138    31139       +1     
==========================================
+ Hits        18840    18847       +7     
+ Misses      10620    10618       -2     
+ Partials     1678     1674       -4     

Files with missing lines	Coverage Δ
bitswap/client/internal/peermanager/peermanager.go	91.85% <100.00%> (ø)
...wap/client/internal/peermanager/peerwantmanager.go	88.54% <100.00%> (+0.03%)	⬆️
bitswap/client/internal/session/session.go	90.56% <ø> (+0.37%)	⬆️
...p/client/internal/sessionmanager/sessionmanager.go	100.00% <100.00%> (ø)

... and 7 files with indirect coverage changes

[hsanjuan]

So we are sure that we have not requested the same CIDs to the same peer via some other session etc. right?

My main worry would be we start leaking something.

[Wondertan]

PeerManager also takes care of deduplication if multiple session want the same data