Feature: mid-replication creation of sets

[mpareja]

From #4 (comment).

Interesting decision to be made. When a client requests replication information for a set that doesn't exist, do we:

• ignore the set and just stream changes for the other requested sets
• return 400 Bad Request so that the client isn't mislead into thinking they will get data from server

One of the pros of returning 400 is that the client would re-try. The current module API allows for late creation of sets, so it is feasible that the server just hasn't initialized the set despite the replication API being available for other nodes to access:

1: const server = uncorded.createServer();
2: doSomeAsync(cb => {
3:  server.createSet('myset');
4: });

The strict 400 Bad Request approach does have a fatal flaw:

• let's say all 5 nodes in cluster are working with set X
• if a user-land service in node 1 is upgraded and introduces a feature requiring set Y, it will not be able to connect to the cluster until the entire cluster has been upgraded

The approach of ignoring unknown sets resolves the above, but comes with its own challenges. If a node's request for information about a set is ignored, it won't receive changes once the server has finished initialized the set. In our example above, if node 2 connects to node 3 after node 3 had executed line 1 but before line 3, node 2 would never see changes for the desired set.

While it is going to be more complicated, it would be ideal if already connected clients magically started receiving changes for the requested sets once initialized on the server.