Support AES encryption of the seda_keys.json file

[Thomasvdam]

Motivation

As our current implementation requires the keys to be present on the application layer for validator nodes we want to at least enable validator operators to encrypt the seda_keys.json file using AES.

Explanation of Changes

I tried to give the operator various options when generating the SEDA keys file:

• By default the CLI will generate a random AES key, display it to the user and wait for confirmation, use that key to encrypt the newly generated SEDA keys file.
• There is a flag --key-file-custom-encryption-key that instead of generating a random key allows the operator to paste/type a custom key through a password prompt. It asks it twice and compares the 2 entries to make errors slightly less likely.
• When both the SEDA_KEYS_ENCRYPTION_KEY environment variable and the --key-file-custom-encryption-key flag are set the CLI errors.

The node now checks whether the SEDA_KEYS_ENCRYPTION_KEY environment variable is set when starting up and if it's missing the node panics. This behaviour can be overridden by passing the --allow-unencrypted-seda-keys flag to the $BIN start command.

I also updated the CLI commands to allow overwriting the SEDA keys file with a flag, and if the flag is not set it will prompt the user for confirmation if it's ok to overwrite instead of errroring directly.

Came across $BIN query wait-tx while researching the flags and figured it would be useful for our contract deployment script.

Testing

Added unit tests for the key file generation and loading.

Changed pubkey CLI add-seda-keys tx unit test to always use --key-file-no-encryption as I wasn't sure how to test commands that require user input.

Updated scripts to use --key-file-no-encryption in the gentx and create-validator transactions.

Manually tested the tx pubkey add-seda-keys command with a custom encryption key, a manually generated encryption key, and an encryption key from the environment variables.

Tested the contract deployment script by running it manually on a local chain.

Related PRs and Issues

Closes: #368

[gluax]

Not leaving direct code comments yet since it's still a draft, but chatting about the ideas:

We should log a warning if the key is not set, probably at an initial check for it. So at least this way there's some visible warning. It should say hey this warning is okay to ignore if this is not a prod environment. Or at least something along those lines is standard.

Is FlagEncryptionKey for passing in the encryption key from the CLI? or for setting the env variable it should use? The wording on the doc comment makes me think you can change the Env var for it.
And if it is the former we should either:

• Disallow this. Passing from plain-text is a security issue. Since this would now be stored as plain text in a file, which is what the env var hopes to avoid. Alternatively, I suppose we could warn hey don't use this CLI option in production mode.
• Or ensure it's from a password prompt, here's a link on why and how this should be done.

Lastly, I think we are fine as far as I could tell looking at the code. But, since this PR's goal is to add in security, we should make sure the env var contents/private keys themselves are never in memory for too long. Or preferably if we have them in memory at all, i.e. more than just as an instant use(although maybe even then), we should use them as byte slices rather than a readable format. It's hard to pick out some bytes among many :). If we do miss it somewhere I imagine this is something a security review would hopefully pick up.