Separable client and server implementations

[aschmahmann]

While it's very nice that we have the protobufs and general message parsing code in a separate package it's unfortunate that go-bitswap insists on instantiating client (sending out wants) and server (receiving and responding to wants) behaviors together. We should have an abstraction that allows us to separately create client and server implementations as well as combine them together.

Some of the benefits we'd get here include:

• Allowing applications that only want to implement one of these behaviors to do so
• Allowing users that want custom client or server behavior to not need to fork/replace both pieces
• Enabling contributors to go-bitswap to experiment with new implementations of server or client code without effecting the other

A couple of the tricky pieces to untangle here are:

1. Even Bitswap clients must be able to receive inbound streams and messages since that is how responses to wants are sent back. In particular, it's a single message-based protocol, rather than request-response, or with multiple protocol IDs for receiving want responses vs receiving wants. This means that our abstraction must enable the client and server to share the Bitswap protocol handler
2. Some implementations may want some shared state between the client and the server. For example, as a server I may want to prioritize sending data to peers that have sent data to me. We'll need to allow the client + server implementations to have access to the same shared state if they so choose.
3. The code inside of the current go-bitswap might be messy to separate out

[guseggert]

Since the server is simpler to implement than the client, I'm starting with the server. I'm also holding Testground tests as a hard requirement for measuring performance. After that, I can look into disabling server functionality on the existing impl, so that we are left with a server and a client.

The last piece then would be some sort of server-client bridging component which combines the two into something resembling the existing interfaces, which @Jorropo is working on.

• [ ] https://github.com/ipfs/go-bitswap/issues/567
• [ ] https://github.com/ipfs/go-bitswap/issues/568

[BigLep]

@Jorropo @guseggert : what is remaining in this issue that wasn't accomplished in https://github.com/ipfs/go-bitswap/issues/568 ?

[Jorropo]

@BigLep I actually finished this while I was doing #568, this is done. #567 can stand alone.