Use dynamic response channels to avoid responses going to every client

[doodlesbykumbi]

Resolves #407

Dynamic response channels are subscribed to, by the request-originator, just before the request is dispatched. This ensures that responses are consumed only by the originator, avoiding unnecessary noise for the other clients.

[y4my4my4m]

I haven't tested it but, if this works as described, would be a great performance boost!

@doodlesbykumbi are the dynamic response automatic or do you need to modify server code to keep track of subscribed channels?

[doodlesbykumbi]

@y4my4my4m The dynamic response is automatic. The idea is

1. Client creates request and subscribes to response channel (prefix + "-response#" + this.nsp.name + "#" + requestId)
2. Client sends request
3. Client either times out or gets all the responses it needs
4. Client unsubscribes from response channel

It's a mostly transparent change for consumers of the adapter. It could be made entirely transparent by having it be backwards compatible, but I think it's better to just go all in.

[darrachequesne]

@doodlesbykumbi thanks for the pull request! If I understand correctly, this change is not backward compatible and will require a synchronized cluster update, isn't it?

[doodlesbykumbi]

@darrachequesne Yes, the current change is entirely backwards incompatible. I think there was a way to maintain backwards compatibility but I opted against it.

[doodlesbykumbi]

I think to maintain backwards compatibility just before dispatching requests we would also have to listen on the original response channel. When we publish a response it would also have to be published on the original response channel.

An edge case (for when dispatching requests) I have to figure out is what happens when by some luck multiple requests take place at the same time. I suppose we'll have to keep a count, and only clean up when the count goes back to 0

[darrachequesne]

Superseded by f66de11.