Event subscription ADR and refactor event_listener module

[liamsi]

tendermint-rs/tendermint/src/rpc/event_listener.rs

Lines 70 to 71 in 71d7e23

	// TODO(ismail): this works if subscriptions are fired sequentially and no event or
	// ping message gets in the way:

tendermint-rs/tendermint/src/rpc/event_listener.rs

Lines 112 to 115 in 71d7e23

	// TODO(ismail): this should live somewhere else; these events are also
	// published by the event bus independent from RPC.
	// We leave it here for now because unsupported types are still
	// decodeable via fallthrough variants (GenericJSONEvent).

tendermint-rs/tendermint/src/rpc/event_listener.rs

Lines 196 to 197 in 71d7e23

	// TODO(ismail): these should be the same as abci::responses::BeginBlock
	// and abci::responses::EndBlock

Subscribe should return a stream of events tied to the particular query. Pretty much what the go-code returns on subscribe but "rust style". E.g. see: https://docs.tendermint.com/master/rpc/#/Websocket/subscribe

Furthermore, the current code only supports two events:

tendermint-rs/tendermint/src/rpc/event_listener.rs

Lines 33 to 34 in cc6a4cf

	EventSubscription::TransactionSubscription => "tm.event='Tx'",
	EventSubscription::BlockSubscription => "tm.event='NewBlock'",

While tendermint actually has more event types:
https://github.com/tendermint/tendermint/blob/6961c7e5d1f2a187bc5f77ac0056ce5ec5bf7ec6/types/events.go#L21-L24

also

tendermint-rs/tendermint/src/rpc.rs

Line 8 in cc6a4cf

// TODO(ismail): document fields or re-use the abci types

ref: #311

[thanethomson]

What level of granularity of event routing to subscribers is needed here? Do we need fine-grained routing to subscribers the way the Go code handles it, or will matching purely based on event type (tm.event) suffice?

[liamsi]

Good question. I think ideally we would replicate the (fine-grained) go behaviour here. It just makes the most sense to me: a dev coming from tendermint go will immediately be familiar with the rust version and it's likely that you want to build (complex) queries and only receive the events for those for instance.

On the other hand the current simpler approach was successfully used in GoZ and as far as I understand the main use case will be specific events in ibc. So if mimicking the go behaviour overcomplicates this we could go with a simpler variant as long as all use cases in ibc can be handled with it.

[xla]

As mentioned in this https://github.com/informalsystems/tendermint-rs/pull/476/files#r465102351 - I think we should take the opportunity and design a query system that fits the language and runtime.