fix: handling socket disconnect error gracefully

[pgte]

Not propagating some error messages that depict that the underlying resource has been closed.
Added an error message to the original Channel destroyed one.
Should fix ipfs/js-ipfs#883

[coveralls]

Coverage increased (+0.2%) to 91.667% when pulling 6b8043b on fix/handle-socket-error into 0425acc on master.

[daviddias]

If the channel is destroyed, the error must be propagated to every muxed stream so that the users of those can request another stream.

[pgte]

@diasdavid does it need to be an error and not simply the end of the stream?

[pgte]

@diasdavid with this change, and at the js-ipfs level, instead of an uncaughtException (which I could not find the culprit of), the stream ends correctly and the peer leaves gracefully.

[daviddias]

Yeah, it needs to be an error that gets emitted in every muxed stream so that each protocol understand that there was an error in transmission.

It seems that one of those errors is not getting caught somewhere in the code and gets thrown to the process.

[pgte]

@diasdavid I guess to makes sense if the protocols presume that the message was delivered if there was no error... In this case, doesn't the Channel destroyed error that is currently being masked also a problem?

[daviddias]

For the sake of the 'protocol' (i.e bitswap, dht, etc) own operations, it just really needs to know that its connection was dropped because of a) was graciously closed, b) some error caused the connection to crash.

We don't propagate specific errors from each transport up.

Makes sense? Not 100% sure that we are in the same page :)

[pgte]

@diasdavid nevermind. I was being guided by this piece of code and this comment, but I admit it looks a bit hacky.

Nevermind this for now then, I'll keep investigating where this error should have been handled.