Change Details

Now the config object is create in the main script and passed down via the `Daemon` to all the various components that need it. We enforce a single instance of a configuration, except for testing. The previous way of doing this, with `set_config` called in the init of SimpleConfig, was not enforcing anything. It was just overwriting the global instance with a new instance every time a new one was created. Luckily there was always a single instance created anyway, except for tests where we are only interested in the most recently created instance anyway. Depends on D18780

Now the config object is create in the main script and passed down via the `Daemon` to all the various components that need it. The previous way of setting a singleton instance of the config consisted of overwriting the previous global config with a new one, but it didn't really enforce anything and just added even more inconsistency. Some functions used the config object created at application launch time passed down via the function params, other functions accessed the global config via `get_config` which could be the same as the one created initially or a new one instantiated later. Right now in GUI mode everything uses the same config, the one created at the application start. In daemon mode, each RPC command still causes a new config to be instantiated and used for this one command. In practice this new config shares some configuration with the existing one (everything that is read from the disk file in which config is commited), and differs via the command line args passed to the client calling the RPC. Depends on D18780

Now the config object is create in the main script and passed down via the `Daemon` to all the various components that need it. We enforce a single instance of a configuration, except for testing. The previous way of doing this, with `set_config` called in the init of SimpleConfig, was not enforcing anything.The previous way of setting a singleton instance of the config consisted of overwriting the previous global config with a new one, It was just overwriting the global instance with a new instancebut it didn't really enforce anything and just added every time a new one was createdn more inconsistency. LuckilySome functions used there was always a single instance created anyway config object created at application launch time passed down via the function params, except for tests where we are only interested in the most recently created instance anywayother functions accessed the global config via `get_config` which could be the same as the one created initially or a new one instantiated later. Right now in GUI mode everything uses the same config, the one created at the application start. In daemon mode, each RPC command still causes a new config to be instantiated and used for this one command. In practice this new config shares some configuration with the existing one (everything that is read from the disk file in which config is commited), and differs via the command line args passed to the client calling the RPC. Depends on D18780