Implement discv5 sub-protocol data transmission PoC

[kdeme]

Implementation + benchmarking of PoC for discv5 sub-protocol data transmission in combination with uTP.

See also ethereum/devp2p#229

[kdeme]

• The draft spec of the sub-protocol: https://github.com/fjl/discv5-streams/blob/main/spec/discv5-subprotocol.md

• Implementation of that: https://github.com/fjl/discv5-streams/tree/main/session

• A draft spec for a fileserver for which you can test a standalone implementation of the subprotocol: https://github.com/fjl/discv5-streams/blob/main/spec/file-server.md

• Implementation of that: https://github.com/fjl/discv5-streams/tree/main/fileserver

[kdeme]

I think the steps to take for this task should/could be something similar like this:

• Read & understand the discv5-subprotocol draft spec and see if there are no big questions or blockers there. Also understand the reasoning why we need this. And if immediate suggestions are there, feel free to give them.
• Implement the discv5-subprotocol spec as a standalone code block. It should be agnostic to how it gets it sessions secrets, consider them out-of-band. Have some basic unit testing for this functionality.
• Implement shared socket (Packet muxer, or rather different handlers per packet). To allow discv5 and discv5 sub-protocol on the same UDP socket. Requires some basic unit tests.
• Benchmark performance of uTP over discv5 vs uTP over discv5-subprotocol with session setup through discv5 talkreq/talkresp. The uTP based fileserver draft specification can be used for this. This will require:
  • uTP over discv5-subprotocol integration
  • fileserver protocol implementation (+ unittests)
  • [Optional?] benchmarking I: benchmark against go implementation to verify if it is in the same ballpark.
  • Have a fileserver protocol that works over discv5 similar like findcontent/content request/response
  • benchmarking II: benchmark the discv5 version vs the discv5-subprotocol version: measure both throughput vs latency (as the latter will have more RTT, you probably want to introduce real delays here).
  • Potentially revise the fileserver protocol with something with less RTT. (Perhaps this should be moved earlier, I do have some ideas here :-))

At any give step it should be tracked when there are blockers or if you see potential improvements to suggest to spec. This can be done here or in separate issues.