Indexer-agent supports operating on multiple Graph Network protocol chains

In order to support smooth subgraph deployment migrations from the L1 network to the L2 network the indexer-agent will need to be able to operate for both an L1 and L2 indexer account but use a single, shared graph-node backend.

Changes

• Query multiple network subgraphs for potential subgraph allocations and update SubgraphDeployment to include a protocolNetwork property
• Add a protocolNetwork property to indexing rules.
  • In the case of a deployment specific rule it will consider this the preferred network; if the deployment doesn't exist on the preferred network it will use the other.
  • In the case of a global rule consider the protocolNetwork absolute not just preference, never use this rule on the other network
• When comparing indexing rules and potential subgraphs the output should include the protocol network where the allocation will be created
• Actions get queued with protocolNetwork specified
• Actions worker will read in the protocolNetwork when taking actions, sending transactions to the appropriate network's contracts
• Update Network.create() to support creating multiple Network class instances; it will now return a map containing all the networks the indexer has passed in.
• Use default allocationAmount for the new rule on L2 created during migration

Interface updates

• Allow n number of chains:
  • Provide multiple values to --network, --networkSubgraphDeployment, and --networkSubgraphEndpointAdd
• Add L2 RPC provider endpoint,
• Add protocolNetwork to indexing rules
• Add protocolNetwork to actions queue

Examples of passing in network params to indexer-agent

Multi-network scenario

--network-rpc goerli:http://rpc-endpoint, mainnet:http://rpc-endpoint
--networkSubgraphDeployment goerli:Qm..., mainnet:Qm...
--networkSubgraphEndpoint goerli:http:..., mainnet:http://

Single-network scenario

--ethereum or --network http://rpc-endpoint
--networkSubgraphDeployment Qm..

Open questions

• Do we need to any changes to indexer-service? Might not need to make changes; there will need to be an indexer-service running for each network.

Next steps

• Turn this into a milestone
  • Break out the tasks into their own issues under the milestone