Corenet exposure

[magik6k]

This describes another approach at ipfs/kubo#2765.

The way it could be done without rewriting API to support streaming protocols is to point corenet service at external(TCP for example) server. API for this would be like

/api/v0/corenet/listen?arg=[listener]&arg=[proto-name]
Listener is address of server waiting for connections from corenet, multiaddr like /ip4/127.0.0.1/tcp/2454. Protocol name would just be service name in corenet.

/api/v0/corenet/dial?arg=[listener]&arg=[peer-id]&arg=[proto-name]
Listener and protocol name as above, peer ID is just corenet peer.

In both cases first packet sent is just peer address as string with byte before it telling address length, after that there is raw communication via new corenet connection.

[whyrusleeping]

The idea is similar to https://github.com/ipfs/xtp

I would be open to trying this, but i'm not sure if its easier than simply fixing the cmds lib to make this work more natively

edit: This is approach would probably be quite a bit easier than fixing the cmds lib to use websockets in a nice way.

cc @jbenet @diasdavid

[Kubuxu]

Also this approach could use any other (streaming and lossless) transport, with minimal support from multiaddr-net, like /unix/ or /pipe/ for unix sockets and named pipes accordingly.

[magik6k]

Closing as ipfs/kubo#3943 got merged