Refactor to ease adding new chains

Context

When we only had EVM compatible chains, adding new ones didn't require much change. To support NEAR (our first non EVM-compatible chain) required multiple refactors, trait additions, etc. When that got merged we wondered what could be improved to ease adding new chains, in the sense of code structure/reuse and boilerplate.

With the recent addition of Tendermint (PR) it's now more clear what could be improved.

Objective

This will be an umbrella issue connecting all possible improvements/refactors that we can do today to ease new chains being added on the code level, requiring less boilerplate code.

Possible improvements

The improvements/questions below were noted after a second revision of the Tendermint integration Pull Request.

• Could we somehow concentrate all build.rs files logic into a single place? Since adding new Firehose chains will always require this to build prost (gRPC library)
• About empty/default implementations:
  • TriggerFilter: could we have a default implementation for this that doesn't do anything?
  • NodeCapabilities: could we have a default when the chain doesn't require anything specific for this?
  • RuntimeAdapter: could we have an empty/default adapter when no logic is needed here?
• DataSource:
  • Should we make the getter code here created by a macro? I mean in the sense that there are tons of similar getter functions that all chains have to do, the only difference are the fields/types themselves.
  • There are some checks that could be done for all chains (eg: handlers > 0). Should we have traits for each type of validation required so the chain chooses to implement what suits best?
• ABI/AS code generation: this is being addressed by #2985
• On main.rs (and related binaries) the part that instantiates the chain code is being addressed by a current refactor for graphman run that I'm currently working on (which will remove other code duplication there as well)

I would love to hear opinions from @tilacog @lutter @leoyvens @maoueh 🙂

Inizia confrontando i file build.rs specifici per chain e il codice di integrazione di Tendermint, NEAR ed EVM, quindi esamina i riferimenti ai trait condivisi, a DataSource e a main.rs indicati nell’issue. Il lavoro è completato quando una o più delle idee elencate vengono trasformate in un refactoring concreto e circoscritto, con accordo sulla struttura prevista e mantenendo il supporto per le chain esistenti.