refactor: Decouple RainbowConfig

[frol]

Resolves #344

TODO:

• Avoid direct reading of the config on the spot (pass all the necessary configuration options throgh the arguments)
  • Avoid reading constant config variables (update the interfaces)
  • Avoid readng config variables constructed at runtime (e.g. eth-{tokenName}-address)
  • Test that all the invocations are passing the necessary parameters
• Avoid direct writes to the config (return value from execute should be treated as diff to the RainbowConfig)

[frol]

FINALLY all the tests are green again!

[frol]

@Kouprin @mfornet Please, review

[Kouprin]

LGTM. Are there next steps after decoupling?

[Kouprin]

CI tests are flaky, I've rebuilt ethrelay catchup one.

[Kouprin]

@frol couldn't find an update at testing/adapter/index.js. Is it included?

[frol]

couldn't find an update at testing/adapter/index.js. Is it included?

@Kouprin It slipped through me when I merged master to my branch. I will see how it fits the new design. Do you think it should be part of the bridge CLI or should be a separate "executable"?

[Kouprin]

couldn't find an update at testing/adapter/index.js. Is it included?

@Kouprin It slipped through me when I merged master to my branch. I will see how it fits the new design. Do you think it should be part of the bridge CLI or should be a separate "executable"?

Both are okay. I think it's a question of our understanding who is the clients of CLI. Adapter is built for testing purposes only.

As adapter asks values from config that are changing in runtime, it's impossible to just pass the args. I guess putting it into CLI in preferable (as CLI is the only source for now who handles runtime-changing config values).

[Kouprin]

@frol Please let me know your thoughts. I can move adapter into CLI in a separate commit, if we will decide to go this way.