Improve chug performance (and clean up the code while we're at it).

[goonzoid]

While doing this Diego story to make Chug work with the new "pretty" log format, I noticed that the API we had introduced when adding the so called "pretty" log format was not the best, and it was making it hard to make Chug generic.

Specifically, having multiple ways to represent a log entry in memory seemed wrong. IMHO, we only need one way to represent a log in memory, and then we can manipulate the information according to the type of JSON we're trying to generate and write later on. I've taken some steps towards that, and the PrettyFormat, RFC3339Time types that were recently introduced are now either gone, or no longer exported. Howerver, in order to get the story done in a reasonable time, we've introduced a pretty ugly bit of code which tries to unmarshal one format, and then if it fails, creates another decoder and tries to unmarshal again. Obviously this is suboptimal, and could get a bit slow when chugging large volumes of logs.

I think there are two ways we could go from here:

• Continue to decouple the types in package chug from those in the core lager package. We should be able to introduce a single type that we can unmarshal all sorts of log formats in to (i think)
• Make breaking changes to the lager.LogFormat type such that it can be used in all cases inside package chug. This breaks API that was supported in the last tagged version, so would need a little coordination with all consumers, but may be the better solution.

When I have a bit more time, I may circle back with specific code examples, etc. Very open to ideas and thoughts on this.

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/157365724

The labels on this github issue will be updated when the story is started.

[sunjayBhatia]

closing this, it involves breaking changes which we don't want to introduce at this time

[sunjayBhatia]

if there are concerns about lager perf. + measurements, we can reconsider

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/169630810

The labels on this github issue will be updated when the story is started.