Introduce an API to establish channels

[danopia]

My goal here is to describe Kubernetes tunneling in a generic way so that it is valid for both types of tunnel transport supported by Kubernetes (SPDY/3.1 and Websockets).

Unfortunately, the two transports are given different semantics by Kubernetes.

• The port-forward API notably doesn't allow creating proxying further TCP sockets after a Websocket is already open, so SPDY is superior for port-forward usecases.
• The exec/attach API doesn't allow closing stdin, and thus telling a program when we're done giving it data, though this is being proposed for a future subprotocol (v5).
• There is a binary-log WebSocket API as well, which doesn't have the stream-multiplexing semantics and is actually just a raw bytestream. There is no SPDY version of this subprotocol. This seems to exist purely to allow binary-safe pod log fetches. I'm uh, I'm not really worrying about this one.

Related:

• exec workaround? #14
• WIP on tunneling pod/exec and pod/portforward #6
• Support for opening Tunnels (via WebSocket, etc) #3
• connectPostPodExec is not implemented deno-kubernetes_apis#2

[danopia]

I'm not incredibly convinced about the amount of abstraction done here. Like, whenever Kubernetes decides to handle WebSocket port forwarding multiplexing, it might not fit into the limited paradigm I have here. But it describes current and near-future PodExec, PodAttach, and PortForward fine, and it should fit into PodLogs as well if there's every any demand for PodLogs over WebSocket (though I don't expect this to be the case).

One particular thing I don't like is the async ready() function on tunnels. For WebSockets it stops accepting new streams, and ideally starts processing inbound messages. But for SPDY it doesn't have anything to do because SPDY streams are independent from each other and the user can make more whenever.. So the function sorta leaks WS vs SPDY paradigms.

Oh well let's go