Extract ClientStream into its own package.

[benjamn]

Right now, client-side access to Meteor's persistent WebSocket connection is controlled by the ddp-client package, which unfortunately includes some large modules like livedata_connection.js that help implement DDP and Livedata, but do not seem necessary for simple socket-based communication with the server.

This PR is the beginning of an effort to make the WebSocket connection usable without also depending on the ddp-client package.

For example, eventually the dynamic-import package might be able to depend directly on socket-stream-client to fetch dynamic modules via WebSocket, without depending on all of ddp-client as well. This would allow dynamic import() to be used earlier in the Meteor startup process, in more fundamental ways, regardless of whether ddp-client is used by the application.

[benjamn]

@stubailo I was able to get rid of this trickery by using different client/server entry points in a separate package.

[hwillson]

Looks great @benjamn - love this decoupling!

[theodorDiaconu]

For example, eventually the dynamic-import package might be able to depend directly on socket-stream-client to fetch dynamic modules via WebSocket,

@benjamn if you implement this, leave the door opened to allow using Meteor without a websocket connection so we can fetch the modules via an http request.

[abernix]

It's a shame this custom error type used a special errorType property.

It seems like we mainly check for this type of error internally, notably tools/meteor-services/auth-client.js#L33 and a couple places in tools/packaging/catalog/catalog.js, but this presumably bubbles into those under some circumstances? Perhaps those should be updated?

Other than that, I did some GitHub code searching to try to hone in on any potential problems, but didn't come across anything concerning or that might be a breaking change, though I suppose developers could be looking for this type of error in their own private code?

[abernix]

Should we start re-branding this error without DDP in it?

[benjamn]

@theodorDiaconu That door will always stay open (just need to swap out this fetchMissing function for one that uses XMLHttpRequests instead of Meteor.call), though every time I've tried that, it's been significantly slower.

[theodorDiaconu]

@benjamn I also noticed that http request will be slower than ddp, but I've recently published a POC package that allows conditionally starting websocket only when you need it.

https://github.com/cult-of-coders/fusion it's hackish but it does the job.
Meteor.call communicates via HTTP when DDP is not active.

I would very much like this to be in the core, or allow a meteor package to hack it somehow... The reason for this is so Meteor can also address the market of apps that don't require a stateful relation with the client.