Add the PeerId of the wantList owner to the protobuf message

[daviddias]

Currently, bitswap leverages the information that swarm has about a connection in order to understand where the incoming wantList are coming from. This creates a dependency that in order for the protocol to work properly, Stream Multiplexing and Identify (a.k.a Id protocol) need to be in place, otherwise, the listener won't be aware of who is sending the want list.

Since IPFS is designed to work across a panoply of devices with different capabilities and with transports that won't always offer Stream Multiplexing (which is a requirement for the Identify protocol), I propose that we add to the wantList message protobuf one more field that includes the peerId of the sender of that wantList (which is also the same message used to send blocks).

This change won't cause any breaking change in go-ipfs. However, if we don't add it, I'll need to change how js-libp2p-swarm works, because the way it is designed favours creating a complete opaque box on how the connection was established to a given peer.

[whyrusleeping]

i'm hestitant to do this as in many cases it will significantly increase the bandwidth consumed by bitswap. Very often we send small one or two key messages to cancel a received block, or to notify that we want another block.

[daviddias]

I see, it is an extra 32 Bytes. It might be inevitable though, for non multiplex connections or some packet switching schemes.

[whyrusleeping]

You should always know who you are receiving packets from, this is guaranteed at different layers, the overhead of adding roughly 40 (34 for multihash, a few for protobuf framing) bytes onto each message, many of which are only 40 bytes themselves is terrible. This sort of thing causes huge bandwidth bloat and waste.

[daviddias]

Agreed, we made it work on js-ipfs in a way that is nice as well :) Thank you!