Subsystems configuration

[stanislav-tkach]

The goals are the following:

• Separate configuration parts that are relevant to some subsystem.
• Load option from the config file with an ability to override them from the command line.
• Give a possibility to change default values (constants).

[stanislav-tkach]

I'm still not sure about what approach would be better here: split the current ChainConfig structure or not, but here is the overview of the current state:

• The node now takes two sub-commands: create-config and run.
• Subsystems need both ChainConfig and a config specific to that subsystem for initialization.
• The version becomes constant.

[stanislav-tkach]

Finally ready to review!

[TheQuantumPhysicist]

The PR is OK. There are two things that I feel can be improved:

1. There's no configuration reading for ChainConfig. There has to be a way to configure ChainConfig itself for functional tests. But this can be made in another PR.
2. The initialization of the config can be improved. All these if lets are very ugly. One solution is to create a wrapper type with a generic trait for a NodeConfigEntry. Then you implement that for all types that can be taken from config (ints, strings, etc). Finally, you can make a method there to load values from Option<T> if a value exists. Maybe you can come up with something else that's simpler.

[stanislav-tkach]

@TheQuantumPhysicist

1. We have a separate test-node, so I see no issues in reading the chain configuration only in functional tests. And yes, I would prefer to do that in a separate pull request.
2. Ideally it can be fixed in clap itself (Allow adding "external argv"s to be parsed alongside/before command line clap-rs/clap#748 and Layering env, args, and config clap-rs/clap#3113), but I don't expect that it will be done in the nearest future. I don't like if let boilerplate either mostly because it can easily lead to an error (reading a wrong value or forgetting to override one of the options). I'm going to think about a better solution.

[TheQuantumPhysicist]

I think this looks good now, besides the minor comments I mentioned.

[iljakuklic]

Looks good. Rather unfortunate there are separate mechanisms for dealing with options coming from a config file and options coming from the command line with this manual translation, but given that, the solution presented here looks rather nice.