Usability improvements, CLI and config

[mzabaluev]

Things to do:

• Node configuration #382
• Improve naming and structure in configuration #384
• Usability: command-line options for node configuration #385
• Movement CLI: organization and usability #386
• Framework for managing secrets #387

[l-monninger]

a more abstract system with node config possibly coming from a networked key-value space or similar.

I believe we want this, but simplicity is paramount as well.

[l-monninger]

@mzabaluev Let's open up a separate discussion for this.

[mzabaluev]

Spun off as #382.

[l-monninger]

Consistent, concise naming in configuration files.

@mzabaluev Let's go through all of our config and state files in a separate discussion.

[mzabaluev]

Spun off as #384.

[l-monninger]

Review CLI commands and option names for consistency and usability.

@mzabaluev I think there are separate discussions for each binary we run here. Can you open them up?

[mzabaluev]

What other user-facing binaries should we consider?
The node binary is one: we can convert most of the settings obtained from environment variables to CLI options.
What else? Faucet?

[l-monninger]

MVP: support local file (separate from config) and AWS Secrets (or KMS?).

I think there should be a generalized backend layer. Again, a separate discussion.

[mzabaluev]

This is now #387.

[l-monninger]

Consider maintaining the CLI "front" binary as a crate hosted in movement.

I actually think a lot of this gets simpler with #340 . Maybe we can recommend an associated clap-compatible pattern?

[mzabaluev]

That's purely for the CLI, different from actors to organize async tasks in the node.

[mzabaluev]

Started #386 specifically about the needs of movement CLI.