chore: address filter and chain config

[mfw78]

Description

This PR tweaks some configuration options for easing deployment on dappnode.

Changes

• rpc, deploymentBlock, watchdogTimeout, and orderBookApi collapsed down into chain-config
• Added ChainConfig option parser
• Added user-defined address filter (only process conditional orders from specific addresses)
• Fixes a calculation issue with the watchdog

How to test

1. Follow the readme instructions for quickly running
2. Observe no errors

Related Issues

Fixes: #72

[anxolin]

I'm not sure this is a good change. It just couple the RPC and block

I still think the block should be independent and should have a default with the deployment block of the contracts.

Then users can override.

Although probably im missing the why this was necesarry, i guess has to do that in dappnode it was not simple to specify the params?

[mfw78]

In either which case, then the deployment block in that case would be optional in the chain-config tuple. Agreed that eventually just publish a composable-cow NPM package that packages up all this info, that can then be re-exported by the cow-sdk. I don't think this is a high priority at the moment and would be better served when iterative work is done on the composable-cow repo with any new order types / interface revision. cowprotocol/composable-cow#60 was created to specifically track this.

The reason to merge them together is to support multi-chain monitoring on DAppNode. Contrary to how the watch-tower is deployed on CoW infra in Kubernetes (where spinning up different deployments is trivial), writing a DAppNode package requires the exact number of containers to be specified for the docker-compose. Once the package is published, the number of containers is not configurable / changeable. So one cannot dynamically select which networks they want to run, and have DAppNode add / remove containers from the docker-compose stack.

Alternatives to this include:

1. Expand the configuration options to allow for specific chains such as --mainnet-rpc etc.
2. Create a separate DAppNode package per chain.

Neither of the above alternatives are a maintainable solution. Both cause maintenance issues if new networks are added, and (2) incurs 3x the costs (each time a package is published to the DAppNode registry, it costs a transaction on Ethereum Mainnet).

[anxolin]

Expand the configuration options to allow for specific chains such as --mainnet-rpc etc.

This seems nicer, at least keeps the independence of the fields. Its possible that you will keep adding more fields of config per network, and i feel is a red flag to add them as comma separated list

what about, for multi-netork support we add:

First the list of networks:

# Either
---network 1 \
---network 2 \
---network 3 \

Or, a bit less nice
---network 1,2.3

Then the params per network

-- rpc-1 RPC1 \
-- rpc-2 RPC2 \
-- rpc-3 RPC3

# or using the name
-- rpc-mainnet RPC1 \
-- rpc-gc RPC2 \
-- rpc-goerli RPC3

This way, adding new params per network feels more natural.

Imaine if we keep this change, and then we add another parameter.
then we will have --chain-config 1,123456,false,asdfg,

If some are mandatory, and some are not, this will be even more painful.

[mfw78]

Having relationships between fields like this is a bit of a nightmare, and IMO is a great reason for a tuple. It's smelly, but I think there may be a more idiomatic way to do this. Isn't this essentially what is communicated by a URL? (ie. <protocol>://<domain>:<port>/<location>).

So, in which case, I think I may actually prefer to use a URL with optional query parameters to indicate fields that are optional. Something like:

<rpc>/<deploymentBlock>?watchdogTimeout=30&orderBookApiUrl=urlencodedField

For example, in DAppNode this would be:

http://erigon.dappnode:8545/17883049&watchdogTimeout=60&orderBookApiUrl=https%3A%2F%2Fapi.cow.fi%2Fmainnet