Event streaming tracker issue

[mariocynicys]

• Complete zcoin tx history testing for wasm (here).
• Create a collective single-request balance enabler for all enabled coins. (feat(event-streaming): API-driven subscription management #2172 (comment))
• Consider using Any for the event message (or T if possible) (feat(event-streaming): API-driven subscription management #2172 (comment))
• Force-enable heartbeat streaming by default for all SSE-connected clients (should send_every config be configured through MM.json?) (feat(event-streaming): API-driven subscription management #2172 (comment))
• Strong type streamer IDs (feat(event-streaming): API-driven subscription management #2172 (comment))
  • And maybe group them into an enum for maintainability (currently one can enumerate all the streamers only by checking EventStreamer implementors) (feat(event-streaming): API-driven subscription management #2172 (comment))
• Integration tests for the streamers.
  • We will want to use a rust SSE reader library for that.
• orderbook streaming.
• best_orders streaming. (canceled because this will require us to either store the whole orderbook for each best_orders pair or introduce a new p2p best orders filtered message).
• Make task managed version of:
  • enable_tendermint_with_assets
  • enable_tendermint_token
• Stream task managed RPCs:
  • account_balance
  • create_new_account
  • enable_{utxo, eth, erc20, qtum, z_coin, tendermint, lightning, sia}
  • get_new_address
  • scan_for_new_addresses
  • init_trezor
  • withdraw
  • connect_metamask
• wallet connect stuff
• Sia:
  • balance streaming (feat(event-streaming): API-driven subscription management #2172 (comment))
  • tx history streaming (feat(event-streaming): API-driven subscription management #2172 (comment))
• trezor_connection_status (the status here wasn't some long to query status, and the the lazy model used in the trezor HW code means that we don't have a thread in the back to inform the client "hey trezor (dis)conncted", but clients (and us) know when they try to use it, when they query RPC)
• Fee Estimation:
  • feat(event-streaming): API-driven subscription management #2172 (comment)
  • feat(event-streaming): API-driven subscription management #2172 (comment)
  • feat(event-streaming): API-driven subscription management #2172 (comment)
  • feat(event-streaming): API-driven subscription management #2172 (comment)
  • feat(event-streaming): API-driven subscription management #2172 (comment)
  • feat(event-streaming): API-driven subscription management #2172 (comment)
  • feat(event-streaming): API-driven subscription management #2172 (comment)
  • feat(event-streaming): API-driven subscription management #2172 (comment)
  • feat(event-streaming): API-driven subscription management #2172 (comment)
• RPC over WebSockets:
  • With RPC (but actually only task managed RPCs are needed for this optimization in relation to event streaming) over WebSockets, we can identify clients without the need for them to provide a client ID (as long as they keep talking via the same websocket and don't use any other means on the side).