viper for configuration state

[cantsin]

• Uses viper to maintain configuration state
• Changed to ini config files (makes Windows support easier)
• If a configuration file does not exist, we automatically write it out (with defaults)
• configuration file search paths:
  • /etc/imls: for *nix osen
  • %PROGRAMDATA%: for Windows; most often C:\ProgramData
  • current directory (.)

[jadudm]

Giving this a read through:

1. We should just remove waterfall, not update.
2. I have questions about i-i-c.
3. Should we keep calls to state, or use viper directly?

For #2, can we even keep IIC? I am going to posit (for discussion, perhaps not here) that this pivot for scaling means that it is no longer possible to set up a pi without access to the server. We'll have some kind of command-line tool for bulk setup, and the assumption will be that you have an admin key to the Directus instance. All of the old setup assumptions are, I believe, invalid with this pivot.

This will come around (per other conversations) around the API key, and how we will no longer be able to... obfuscate it, for lack of a more honest word.

So, this seems like an OK commit, and I say merge, but I also think we should just throw out the tools that are no longer part of this pivot's work. (Or, perhaps we have too many threads in too many places to keep track of this stuff, and should put some more things in the GH...)

[jadudm]

Ah... above, #3... in my spike exploration, I kept a few calls to state, because they were wrappers around viper calls that did a small amount of work. (Or, they were state stored outside of viper.) Should we remove calls to state wherever possible, or should we leave it there as a kind of abstraction? (It becomes a very thin abstraction in roughly 80% of uses.)

[cantsin]

1. Before we do remove waterfall, are these images still useful going forward? that is, could these images help inform the data visualization process? (maybe this is a question for @sknep) -- I was thinking we could keep a few images along with the associated data so we could do a before/after "see how much we've improved with data viz!" comparison.
2. Absolutely; let's remove i-i-c.
3. Indeed config is 80% a thin abstraction. I'm happy to remove config when it becomes even thinner. Right now, it is still useful for e.g., GetDurationsURI and all the other parameters we have to calculate from the configuration. So I'm inclined to leave it in.