Potential for race condition in bitswap

[whyrusleeping]

Making this issue to track a potential race condition in bitswap. When adding a block to bitswap, the incoming block is passed through to the notifications lib and published to anyone waiting for that block. In the case that someone has called GetBlock on the block and then we add it locally, two different goroutines would have the same 'block'. This is only a problem in cases where we mutate the node on the adders side after the add call.

Doing a simple ipfs cat h(X) in one shell before h(X) exists, and then running ipfs add X does not even trigger the race detector.

[whyrusleeping]

@Stebalien I think we fixed this issue recently, right?

[magik6k]

ref #4169, looks fixed

[Stebalien]

I think this is a non-issue and unrelated. This appears to be about returning the same block object to multiple clients which should be totally fine (they're immutable (well, we copy before mutating at least).

[eingenito]

Closing as fixed.