feat(starknet): firehose trigger filter
Supersedes #5201.
This PR adds 2 trigger filters to Starknet:
- block trigger that specifies a list of ranges
- event trigger that's capable of filtering by contract address, event topic, and block ranges
When used without turning on the filters feature on the Firehose provider, these filters only work on the graph-node side - meaning that full blocks are still always streamed to graph-node. Filters are applied only to avoid excessive trigger parsing. This part was what #5201 enabled.
What's new in this new PR is the additional implementation of Firhose triggers (i.e. to_firehose_filter), allowing graph-node to send a transforms field in its Firehose stream subscription requests when the filters feature is enabled for the provider. Note that all blocks are still always streamed - the filters only affects the list of transactions that are included (which dominates the size of blocks streamed as block headers are thin).
This new feature should (haven't benchmarked though) significantly improve Starknet subgraph indexing performance, as the actual data sent over the wire should now be much smaller for most real-world subgraphs. (Notably, if a subgraph tracks ETH transfers for example, it won't see much difference as ETH is transferred to sequencer in most transactions)
firehose-starknet has already implemented support for filters. This PR has been tested against that implementation and it works as expected - blocks without matching events have empty transactions, and those with matching ones only come with relevant transactions.
Pushed changes:
- encapsulated trigger filter logic
- renamed a few type aliases to reduce ambiguity
- added trigger filter matching tests
Notably, since the trigger filter type is now completely encapsulated, it's now rather difficult to construct a TriggerFilter instance from chain.rs. So I just tested everything inside adapter.rs instead.
As I understand it this integration was taken in a different direction, I'll close the PR for now, re-open if needed. Also if not needed anymore would be great to remove the existing stakrnet code.