Refactor: Config to Application State

[justenwalker]

For #128

This is an initial stab at factoring out the application state from configuration. One cool thing about this is that many (all?) of the global variables go away.

I also added support for telemetry reload (hopefully, I have not tested this extensively)

I thought I'd get this out in the open so that everyone can poke some holes in it.

cc: @tgross

Work in progress

One thing I'm not too happy about is the proliferation of methods that I implemented on the Config struct. I think the next step would probably be to push that logic into the packages themselves. I've had some success implementing configs as some high-level structure containing mostly maps and using github.com/mitchellh/mapstructure - since it supports weak typing which would be good for things like #122

[tgross]

I'm still digging into details as there's a lot here, but just want to say this is some damn nice work @justenwalker

[tgross]

One thing I'm not too happy about is the proliferation of methods that I implemented on the Config struct. I think the next step would probably be to push that logic into the packages themselves.

What I've noticed is that there are broadly two categories of methods there. There are some that are thin wrappers on somepackage.NewSomeStruct that check for nil and that's about it. Those NewSomeStruct all take json.RawMessage, so maybe there's a nice way to define a function type for those and then push them into the packages as you've suggested.

The second category are those that are building exec.Cmd and stuff like that. I suspect we don't want to try to move those out of the core package because it's going to cause us heartburn around imports. But moving them into functions that can be tested in isolation (in core/commands.go lets say) could be useful.

[tgross]

Not necessarily in scope for this PR, but omitempty is really only used when we serialize a struct, right? Maybe we don't really need this annotation.

[justenwalker]

Yeah, we can remove it - we really don't re-serialize the config anyway, so the extra tag options are mostly useless.

[justenwalker]

@tgross There is a lot here. I broke it out into individual commits that should be hopefully self-explanitory, but I'll summarize:

• I took care of most of the comments that you made in the previous commits
• I did some refactoring of the implementation classes to use interface{} instead of json.RawMessage for reasons that become a little clearer after you read the source code.
• As a result of using mapstructure for decoding configs, I've completed Allow numeric configuration values to be passed as strings #122 (tested in 9776ebf)
• I put in the ordering fix from change ordering to allow prestart script to SIGHUP containerpilot #140 (see 2500db4) so that reaping happens first before everything, and signal handling starts before preStart runs.
• Fixed up the add-dep target in the makefile, it didn't seem to work when I added mapstructure

[tgross]

prometheus/common/log? What happened to logrus here?

[justenwalker]

Ah, my auto-importer often gets the common names wrong :(

[tgross]

One last little comment about the log import in config/commands.go but otherwise this LGTM.

[tgross]

LGTM.