Support multiple networks

[onbjerg]

It would be cool to support multiple networks such as Rinkeby where Aragon is deployed.

A simple implementation of this might be as follows:

• We run a worker for each network we want to support, each with an environment variable ETH_NETWORK set to their corresponding network name.
• Every top-level document (such as entries in the orgs and apps collections) have a property network attached to them
• The API should be able to filter on these top-level documents using a network name
• The website should have a simple dropdown with the supported networks

I estimate that if the feature is implemented like this we would be looking at around 4-5 hours of work with the caveat that infrastructure costs will scale linearly with the number of networks we support, since we have to run a worker for each network. Furthermore, if we want to eventually run archive nodes, then we'd have to run one for each network too.

Networks we should support:

• Mainnet
• Rinkeby
• Flora

[onbjerg]

I'm going to mark this as a good first issue while providing my thoughts on how this could be implemented:

The easiest way to set this up is to run a worker per network. The only environment variables we would need to change are ETH_NETWORK (as described above) and ETH_NODE. Each worker would use the same database for simplicity in terms of accessing the data on the same front-end and via the same API. We could also decide to separate these aspects, i.e. have a separate database, API and front-end for each network.

Based on ETH_NETWORK some things need to change in the worker:

If we go with the first option (one database and API for all networks), then each document would need to have a network property populated with the value from ETH_NETWORK. If not, this step can be ignored.

Furthermore, there are exists some network-dependent configuration, namely the address for the different kits and the address of the ENS registry.

At first we could just have a file with different values for each of these sets of data much the same way that the Aragon client does it. However, I think a more nice solution long-term would be to have the worker load a configuration file (something like json) with these values. This would allow people to run Apiary for their own custom networks.