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 🙂

首先比较各个 chain 专用的 build.rs 文件以及 Tendermint、NEAR 和 EVM 的集成代码，然后检查 issue 中提到的共享 traits、DataSource 和 main.rs 引用。完成意味着将列出的一个或多个想法转化为具体且范围明确的重构，就预期结构达成一致，并保留对现有 chains 的支持。