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 🙂

Commencez par comparer les fichiers build.rs spécifiques à chaque chain ainsi que le code d’intégration de Tendermint, NEAR et EVM, puis examinez les références aux traits partagés, à DataSource et à main.rs mentionnées dans l’issue. Le travail est considéré comme terminé lorsqu’une ou plusieurs des idées listées sont transformées en un refactoring concret et délimité, avec un accord sur la structure prévue et le maintien de la prise en charge des chains existantes.