Add verbose mode to ipfs swarm connect

[whyrusleeping]

It would be nice to get a log of what the dialer is trying and how each thing succeeds or fails:

$ ipfs swarm connect /foo/bar
Trying /ip4/1.2.3.4/tcp/12312
Trying /ip4/127.0.0.1/tcp/4444
From /ip4/1.2.3.4/tcp/12312: Error, connection refused
...
...
etc

[kevina]

This should be easy. @whyrusleeping do you want me to do this?

[whyrusleeping]

@kevina Sure, go ahead. It may require digging into some libp2p stuff, but it shouldnt be too difficult

[kevina]

I think the best way to do this would be to use WithValue/Value in context to set the value to either a channel or a writer where Connect can send debug output to if it is defined. This should be sufficient to allow passing the information you want but I am not that familiar with that part of the code.

@whyrusleeping thoughts.

[whyrusleeping]

@kevina I like the context approach. Its probably important here to clearly define what the interfaces should look like. Other than that, go for it.

[kevina]

As far as the API goes the output is now:

{"Strings":["connect QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ success"]}

Since the doesn't have any structure already, if the --verbose option is given there will simply be more values in that list. This will unfortunately not stream the information as it happens, I can do that but then the output will need to be different, maybe something like

{"Message": "Trying /ip4/1.2.3.4/tcp/12312"}
{"Message": ...}
{"Strings":["connect QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ success"]}

That is each debug output will be send as a separate json value with the final value being the normal output.

For the value added to the context I think I will call it "DebugChannel" and have the value be a string channel. (Or I could make it a generic interface{} channel but I hate all that extra casting.) If the value exists then debug strings will be sent to it.

[kevina]

@whyrusleeping could I get some feedback on this

[whyrusleeping]

I dislike the current api. Its really not a good format, and isnt machine parseable at all. I think we can get away with changing it here.

A better format moving forward could look like repeated messages of type:

{
  "address": "addr dialed",
  "event": "begin|success|error",
  "message": "error if error",
  "extra": "maybe details such as 'reuseport' or other dial options here?",
}

What do you think? cc @Kubuxu @lgierth