Refactor the keystore and override the account by the one in the key file after decoding the key from the mnemonic

[romac]

Closes: #751
Closes: #636

Description

• Refactor the keystore
• Override the account by the one in the key file after decoding the key from the mnemonic
• Allow importing a key either from a key file or directly from a mnemonic
• Add key restore command

Note: This PR is best reviewed one commit at the time.

New interface of keys add

USAGE:
    hermes keys add <OPTIONS>

DESCRIPTION:
    Adds a key to a configured chain

POSITIONAL ARGUMENTS:
    chain_id                  identifier of the chain

FLAGS:
    -f, --file FILE           the path to the key file (conflicts with --mnemonic)

New interface of keys restore

USAGE:
    hermes keys restore <OPTIONS>

DESCRIPTION:
    restore a key to a configured chain using a mnemonic

POSITIONAL ARGUMENTS:
    chain_id                  identifier of the chain

FLAGS:
    -m, --mnemonic MNEMONIC   mnemonic to restore the key from

---

For contributor use:

• Updated the Unreleased section of CHANGELOG.md with the issue.
• If applicable: Unit tests written, added test to CI.
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
• Updated relevant documentation (docs/) and code comments.
• Re-reviewed Files changed in the Github PR explorer.

[andynog]

I think these changes are good for now. If it's working on the tests and transactions are signed then should be OK. But probably for the next release we should look into the whole key support (keyring, sign_tx with cosmos_tx, allow to import keys with mnemonic).

[andynog]

I think overall the changes are good, but just thinking if we should have the mnemonics under keys restore

[andynog]

I've did a quick test, keys add and keys restore works fine, but a couple of observations:

1. The keys add command you don't need to specify the name parameter. It takes from the config, while the keys restore you have a name required parameter. Should we remove that and also pick from the config ? Or implement the name for keys add ? If the parameter is required, then the key_name in the config is to specify which key will sign the tx (since the name allows multiple keys)?

2. When I try to list an existing key (added with a previous hermes version) I got an error. So we might need to ensure users re-import keys if they are not compatible between versions, might be just an observation on the guide or changelog

hermes keys list ibc-1
Error: key store error: cannot ready key file

[romac]

1. Right! I think we should remove the --name parameter since at the moment we always sign txs with the key from the config, no?

2. Oh good point, I hadn't thought of that. If you think it's best, I believe I can ensure that we stay backward compatible, by keeping the store key file format the same as the input key file?

[andynog]

1. Right! I think we should remove the --name parameter since at the moment we always sign txs with the key from the config, no?

I think we should remove that for now. If one day we allow passing the account to sign the tx then we can allow that.

2. Oh good point, I hadn't thought of that. If you think it's best, I believe I can ensure that we stay backward compatible, by keeping the store key file format the same as the input key file?

I don't think we need to ensure backward compatibility. I think the format is OK, in the end most people will just use the mnemonic option and only the relayer uses that imported key, there's no export functionality. So I think this is good. We just add a message to breaking changes in the changelog.