WIP: Feat/memory transport

[pyropy]

Closes #2293

[MarcoPolo]

Friendly reminder to test your transport by adding a case here:

go-libp2p/p2p/test/transport/transport_test.go

Line 69 in 581571b

var transportsToTest = []TransportTestCase{

[pyropy]

Friendly reminder to test your transport by adding a case here:

go-libp2p/p2p/test/transport/transport_test.go

Line 69 in 581571b

var transportsToTest = []TransportTestCase{

Thanks, will add it.

Could you possibly take a look at this PR multiformats/go-multiaddr#256 ?

Edit: This is the issue I'm currently having while running my tests

Error:       Received unexpected error:
        	   failed to parse multiaddr "/memory/1234": unknown protocol memory

[pyropy]

I have few questions:

• When OpenStream is called on the Connection, how is the returned stream used? Is the AcceptStream called after OpenStream? My concern is about how the channels would be exchanged between the opened streams for the connection. I guess if OpenStream call is followed by AcceptStream we can send stream to "remote" connection.
• Should we keep using io.Pipe or switch it up with channels? I've seen that io.Pipe is using channels in the background.

[sukunrt]

When OpenStream is called on the Connection, how is the returned stream used? Is the AcceptStream called after OpenStream? My concern is about how the channels would be exchanged between the opened streams for the connection. I guess if OpenStream call is followed by AcceptStream we can send stream to "remote" connection.

OpenStream and AcceptStream happen on different libp2p hosts. Consider two hosts A and B. When A calls OpenStream, it creates a stream it can write to and read from. B will get this stream when it calls AcceptStream on the connection.
In the swarm, AcceptStream happens automatically because every open connection is waiting on AcceptStream here: https://github.com/libp2p/go-libp2p/blob/master/p2p/net/swarm/swarm_conn.go#L118
For implementing a transport, the transport should buffer streams till they are accepted by calling AcceptStream.

Should we keep using io.Pipe or switch it up with channels? I've seen that io.Pipe is using channels in the background.

I think io.Pipe is fine. This transport will only be used for tests, so it's nice to get as much of the work done by the stdlib as we can.