Lifecycle issues (destroy/close/hangup/etc.) #2
Description
The tunnel.destroy() method is now how you get the tunnel to emit a 'close' event. Adding this sort of twisted a knife of uncertainty/doubt as to all sorts of "lifecycle" issues that I can't claim to have fully addressed.
This is sort of a weird situation: we're imitating sockets, over a tunnel that is probably pipe to/from a socket, but all we're really dealing with is streams. But these streams are duplex, both at the tunnel level and at the substream level.
So, say, what would it mean if the tunnel were transported over an allowHalfOpen: true stream? That's really not a supported configuration! But is there any sort of gracefully shutdown that we'd want to try do?
The driving use case for this is of course the Tessel proxy system, and so its somewhat a question of: if the tunnel socket has an error, what does that mean for the subsockets? On the other side of the situation, should there be a less "forceful" way to shut down an idle tunnel than calling .destroy() on it? [For node.js sockets .destroy() means something much more drastic than .end(), but we don't really have an equivalent of the latter given the allowHalfOpen point above…]
Some of this may just be handwringing — I think in practice the solutions in place (forward transport errors to the tunnel/substreams via tunnel.destroy(error) and signal general tunnel decommissioning via tunnel.destroy() with no error) in theory cover the immediate needs.
Perhaps though, there should be a way to signal a clean shutdown to the other end? Would this be something useful built-in, or can apps already leverage tunnel.sendMessage() for any use cases where that sort of signaling would be desired?