Add support for specifying the cli args for running a node from config file

[liuchengxu]

Currently there are already dozens of FLAGS and OPTIONS shipped with the default node executable in substrate, it would be very convenient to also support reading these command line options from a config file like JSON, TOML, etc, especially helpful when we are to pass the bootnodes from the command line.

Using a config file is generally better than writting a bash script for the advantage of cross platform, even most substrate developers/users use Linux/macOS system I guess.

The proposal is to add an option --config-filename <PATH> for writting the command line arguments in a file, and the same option specified in this config file will be overrided by the one passed from the command line if it can have only one value.

[liuchengxu]

I have a workaround for this feature, the idea is to mock the cli args using a faked option --config-filename.

1. add a fake OPTION --config-filename <PATH>. This option actually does not exist in substrate cli, or can be used as a mere prompt.
2. parse std::env::args_os() to extract the value of --config-filename if there is one.
3. read the config file specified by --config-filename, let's say it's a JSON, the key of which is the origin FLAG/OPTION, the value is same with what we pass from the command line. For this JSON file, the nested config is unsupported, i.e., only Bool, String, Number, Array are supported, the entry of this JSON can't be an Object.
4. build an iterator in the form of --key=value from the above object and pass it into SubstrateCli::from_iter().

Basically it's to perform a preprocessing manually on the origin cli args. This approach does work and has no need to do much changes to current code, but kind of hacky.

Then you can run the node using substrate --config-filename=config.json

config.json:

{
  "chain": "local",
  "validator": false,
  "rpc-external": true,
  "ws-external": true,
  "log": "info,runtime=debug",
  "port": 20223,
  "ws-port": 8089,
  "rpc-port": 8088,
  "other-execution": "NativeElseWasm",
  "pruning": "archive",
  "syncing-execution": "NativeElseWasm",
  "block-construction-execution": "NativeElseWasm",
  "db-cache": 1024,
  "state-cache-size": 1262485504,
  "name": "Hello World",
  "base-path": "validator-db",
  "keystore-path": "keystore",
  "password": "password",
  "bootnodes": [
        "/ip4/172.16.216.236/tcp/31128/p2p/QmdqTe9ykXgxWemhLXGmiuWQe3fEYuDRiwDgTDL1Npen6s",
        "/ip4/172.16.216.236/tcp/31128/p2p/QmdqTe9ykXgxWemhLXGmiuWQe3fEYuDRiwDgTDL1Npen6s",
        "/ip4/172.16.216.236/tcp/31128/p2p/QmdqTe9ykXgxWemhLXGmiuWQe3fEYuDRiwDgTDL1Npen6s",
  ]
}

If you run with substrate --chain=staging --config-filename=config.json, the "chain": "local" will be overrided by --chain=staging. I can prepare a PR if you think this could be a short term solution. It might be very useful for the devops having to play with a lot of cli options.

[bkchr]

Basically this is blocked by this: clap-rs/clap#748

I'm not such a huge fan of introducing a another hack into the cli.

[s3krit]

I believe this is a duplicate of #5887

[liuchengxu]

Yeah, they are essentially the same thing, feel free to close this one :(.