Refactoring of the CLI

[alexauroradev]

Some relevant issues from the past:

• Design and MVP of new Bridge CLI and Lib API #351
• Cleanup CLI --help #308

[mfornet]

Some ideas that have been discussed:

Enhancements

• Rewrite the CLI in TypeScript, it will be easier to follow the code, to contribute, and a good way to avoid silly mistakes that have already happened on the past.
• Separate logic that should go to the library and the cli (related Extract RainbowLib #297)
• Improve commands and argument help. (Cleanup CLI --help #308)

From @ilblackdragon in #338 (comment)

• Don't use classes where classes are not needed. Remove extra folders. If class is 1 method or 1 initializer and 1 run - it should not be a class.
• Add utilities, like remove0x also use web3.utils that have a rich set of things
• Replace maybe create account, etc with near-api-js APIs for all this
• Leverage NEAR's key management. Do similar thing for ethereum.

It requires some investigation to figure out what is the best way for key management in ethereum. Instead of managing keys directly in the CLI we can have a Provider that allows us to sign messages, the key doesn't necessarily be in memory, it can be in web wallet, hardware wallet, etc...

With this done we should move the secret keys out of the config file.

• Switch to use yargs / configs

In this case we can keep commander and configstore (not a strong preference) but definitely need to remove this. This is possible per the commander documentation.

• Use truffle artifacts to locate artifacts like abi/bin instead of managing them manually.

I propose we start using https://hardhat.org/ for this, since we are migrating our tests involving ethereum contracts to hardhat.

New features

• Handle multiple configurations at the same time. Right now CLI only reads configuration from ~/.rainbow/config.json. The proposal is to have one extra argument that allows to have named configurations. This will be useful for bridge management, when we want to interact with different bridges from the same machine.

• Add status command, that fetch useful data of the bridge and reports its status. It will help, among other things, for monitoring and health checks.

• Add start/stop command that initiates a new bridge in a single command, deploying all required contracts and starting relevant services. Stop command should stop all active services. We should have verbose information of all steps, including hashes of the contracts to deploy or that are already deployed. Since starting requires a lot of arguments, we can prompt the user for them in case they are not provided in the config, and have prompts for actions that will spend tokens, for safety reason.

• Add commands to handle upgradeability. (Pause contracts, migrate state, redeploy new contracts).

[mfornet]

Re-organization

I propose to move all command of the CLI related to the token-connector from this repository to the rainbow-token-connector repository, so we don't need to maintain code in this repository related to it. Commands related to token-connector are those that deploy the connector contract to both networks, and those that execute transactions between networks (notice that the latter are made for testing only).

However we still want to have access to the token connector commands (and probably have it as a dependency)

1. Since we want to install only one CLI application that exposes all commands.
2. Tests on this repository uses the connector to check that changes were good.

How to do it

To avoid duplication of the code on both repositories (thinking about configuration storage mostly) I think we should split current CLI in three components:

1. rainbow-bridge/cli/lib [Contain elements and convention that are commons to all cli applications, like configuration storage interface and connection interface].
2. rainbow-token-connector/cli (Depends on 1) [Contain the cli to interact with the connector, mainly speaking, deployment and transfers]
3. rainbow-bridge/cli/app (Depends on 1 and 2) [Meta CLI that brings all commands from (2) and potentially from other future connectors like eth-connector if necessary. Exposes all commands to deal with relayers and the bridge in general].

Important: Before making this changes let's discuss the role of rainbow-bridge-client repository.

Motivation

While updating the token-connector several changes to the interface of the contract were done, and it involves updating the way off-chain tools are interacting with these contracts. Ideally those tools lives in the same repository so making changes and tests is more straight forward.