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 🙂

Comienza comparando los archivos build.rs específicos de cada chain y el código de integración de Tendermint, NEAR y EVM; después, inspecciona las referencias a los traits compartidos, DataSource y main.rs mencionadas en el issue. Se considera completado cuando una o más de las ideas enumeradas se convierten en un refactor concreto y acotado, con acuerdo sobre la estructura prevista y manteniendo el soporte para las chains existentes.