added channels router

[zodeak]

channels pub/sub can be routed to concrete tarantool instances

Proposed changes

added shards routing ability (for tarantool engine only)
clients can subscribe channels to subset of tarantool shards
each channel can be subscribed to multiple shards

at now all instances/shards are all the same and consistent hashing is used to select one of them
but we can have tarantool instances with different roles and each instance has its own set of channels

this patch adds flexible rules how to subscribe channels to shards

config example:

{
  "tarantool_address": ["shard1-addr1,shard1-addr2", "shard2-addr1,shard2-addr2"], // here we describe all avail instances
  "router": {
    "routes": [
      // here the rules to subscribe channels to exact tarantool shards
      {"name": "channel1", "addresses": ["shard2-addr1"]}, // (exact routing) any address of needed shard
      {"name": "channel2*", "addresses": ["shard1-addr1", "shard2-addr1"]}, // (the longest prefix routing) * means prefix, here we subscribe to two shards and will receive mesages from both shards
      {"name": "__default", ["shard2-addr1"]} // force to use default route if none was found
    ]
  }
}

presence/publish/history is not yet implemented

limitations for multi-shards routes:

publish cannot do it atomically, so duplicates will be if client re-publishes on error (if some of shards will die)

history cannot return just one StreamPosition, so new history api is needed (and what to do with old one?)

[FZambia]

Hello, thanks for the pr.

I looked at the description and code – did not understand the motivation fully.

What I could understand - possibility to use custom sharding strategy based on channel instead of built-in consistent sharding. I.e. to pin Centrifugo to a particular Tarantool shard responsible for some channel.

But this PR adds more than that - subscriptions to multiple shards for the same channel - and that's sth I do not understand and which does not fit Centrifugo design where channel always corresponds to one shard. I doubt it makes sense for Centrifugo to add logic to the code base which is orthogonal to the design.

So we definitely can't proceed with this in the current form, probably if I understand the motivation to have multiple shards for one channel I will be able to suggest something. Or maybe not since it seems too different from the current model.

[FZambia]

Strategy to discuss:

1. Use shard channel to publish
2. Use __сhannel field in Publication.Meta. This field has priority over the broker channel. Stripped when broadcasting to local clients.
3. Func to re-match Publications with overloaded channel (probably not necessary)
4. Sharded parallel processing by the overloaded channel name if possible