Subscription and Websocket multiplexing

[gbjk]

Overview

Now that subscription configuration is nearly universal, we can start to address abstracting the solution, and learning from the issues with multiplexing subscriptions.

Required features:

• Support connections per asset class
• Support runtime subscriptions, including FlushChannels
• Enabling pairs after subscription must work
• Support N+ connections due to subscription cap or rate-limiting
• Exchange base functions like SubscribeToWebsocketChannels need to work for both types of exchanges

Design

• Remove Subscriptions and GenerateSubs from belonging to connections
  The most pressing reason for that is that in a world where we might establish N+ connections due to connection rate limiting,
  We can't possible generate the right subscriptions and (in the darkness) bind them at the connection level.
  I believe Subscriptions must be an exchange level entity, which are then allocated to websockets in a one-to-one relationship.
• Router middleware to map connections and subscriptions
• Just-in-time connections after the first connection
• Separate Subscription configuration from runtime subscriptions
  • So that "All pairs" continues to work with FlushChannels
  • So we can always re-derive the store from the fanned out subscriptions
• Unify the does/doesn't nature of multi-connection websockets. Everything should just be the same

References

• gateio: Add websocket request functions for futures trading (btc and usdt margined) #1603
• websocket/gateio: Support multi connection management and integrate with GateIO #1580

[gbjk]

Requirement added from #1785