Improve the transport creation experience

[tomaka]

Creating a transport is a bit of a message because of modifiers everywhere (eg. https://github.com/paritytech/substrate/blob/ed2faf445f8849e8d90ddadc684ac2658819e55f/core/network-libp2p/src/transport.rs#L30-L60).

Needs some API design thoughts.

[romanb]

What do you mean by "modifiers"?

[elferdo]

In the same vein, I think we should be able to test the higher level logic without depending on specific transports, for example: https://github.com/libp2p/rust-libp2p/blob/603c7be7c21164a82b5f71ad746254a36a90c02b/protocols/kad/src/behaviour/test.rs#L67.We introduce TCP just to test if one node gives the correct result back. I think we could pack all the network complexity behind proxy objects that could be substituted for shallow doubles in tests.

[tomaka]

@elferdo There's a MemoryTransport that does the equivalent of TcpConfig but keeps communications inside the process. But then you need some multiplexing on top, and writing a multiplexing layer is quite complicated.

[elferdo]

Ok, thanks for the pointer of MemoryTransport. What I was thinking is more that to test whether Kademlia finds a given PeerId as the closest one to another PeerId we shouldn't really need any networking stuff. I feel that the coupling between logic and networking is too strong there.

[romanb]

Closed by #953.