Muxing and streams

[lrettig]

Rather than one stream per type, we may want to switch to a single master event stream that a client can subscribe to. The client can optionally pass a filter when setting up the stream if they only want to receive a subset of event types. Some advantages:

• this is easier to handle on the client side - rather than needing, e.g., seven logical threads to monitor seven types of events, the client can use a single logical thread (with a case/select statement) and demux/dispatch handling of different event types
• it maintains optionality since, if the current behavior is desired, the client can just create seven different event streams, each filtering on a specific event type

We should look into whether there's an existing specification language/DSL we can use for the filtering/stream definition.

[avive]

We have a real api customer on the team - @IlyaVi - we should ask with him what he prefers as a wallet builder and consider his feedback. Also - per @antonlerner feedback - we should look into pub-sub vs. grpc for the api implementation framework.

[lrettig]

Looking into pub sub is on my to do list

[lrettig]

This work has been done. Results are in spacemeshos/SMIPS#13 and spacemeshos/SMIPS#21. We ended up implementing multiplexed streams in the API (see linked, merged PRs). I looked into pubsub and that conversation is ongoing in the implementation SMIP. We don't have any fancy DSL or anything for filtering now but we can look into that in future if necessary.

@IlyaVi @ilans @AmitShaul please let us know if you need any changes made to the streams as defined!