Handle ConfiguratorError in determine_user_specific_data

[czarte]

Instead of Panic we could use an ConfiguratorError to ignore the settings and just return Error Message to the UI, to communicate with the User the message to change provided information about config.toml

If the config file is given with a naked relative path (name.toml), the data directory must be given to serve as the root for the config-file path.

In get_config_file_from_mc we do Panic, instead, we could return Error and propagate it to the caller config_file_data_dir_real_user_chain_from_mc and from there to the determine_user_specific_data where we can return ConfiguratorError and handle it appropriately

[dnwiebe]

It's a bit dangerous to do the same configuration validation in the Daemon and in the Node in different ways, because the two sets of logic will eventually get out of sync with each other and cause problems.

However, the configuration could probably rearchitected into a collection of small validation/configuration pairs, one for each tiny piece of configuration that has to be done. There could be one trait implemented by all the pairs, perhaps with a validate() method and a configure() method.

Then the little configuration pieces could be collected into two bundles: one that includes only validations that can be done both by the Node and by the Daemon, and one that includes all the pieces. The Daemon, when called upon to start the Node, could run through its list of validations (ignoring the configuration option of each pair) and reply to the start command with intelligible error messages if it can tell that the Node wouldn't start successfully.

If the Daemon runs through all its validations successfully and thinks there's a good chance the Node will start, then it could generate and execute the command line as it does now; if the Node noticed a discrepancy the Daemon couldn't see, we'd get the same kind of failure we get now.