chifra: two different ways of parsing TOML in one package

[dszlachta]

In config package, we have two different ways of parsing TOML configuration files.

• root_config.go uses viper
• block_scrape.go uses github.com/BurntSushi/toml

Additionally, block_scrape.go reads values from environment variables using custom code, which can be incompatible with viper

[tjayrush]

Just to remind myself, there are three reasons I made scrape config different than the base trueBlocks toml file

1. In the C++ code, some of the config items were multi-level -- I could set a default value for all tools (such as say, a display string) and then customize it per tool. I did this by merging the toml files, reading the trueBlocks.toml first and then overlaying values with the tool's customize TOML. It wasn't clear if this is possible with Viper.

2. I wanted to be able to auto-generate the documentation for the configurable values and the easiest way to do that is with the existing makeClass tool.

3. I didn't like the way the existing TOML reading code forced itself into the calling code with a clunky interface. I wanted to be able to call a routine and get a 'settings' object returned.

I admit that the code may be more complicated than it needs to be, but it does need to be self-documenting.

[tjayrush]

I put a TODO comment in the source code and copied the code for the Viper way doing config files into the source. Search for the text "issue #2259" to find it.

[tjayrush]

We should use this: https://github.com/knadh/koanf

[tjayrush]

This is now fixed. Closing.