Robustify logging configuration

[lottspot]

Currently the logger uses the default transport, which is stdout. Since the API process is run by upstart, everything written to stdout is lost. We should work out how we want to approach configuring logging transports which will ship log entries to a location that they can actually be saved and later analyzed if necessary.

[modpluz]

Perhaps we could explore morgan as an alternative?

[lottspot]

So this issue was probably poorly titled. I don't think our logging support is itself insufficient; we are logging errors within every single controller. What is insufficient is that our loggers currently spit these log messages to stdout. Thats fine for development, but is no good in our production environment. We can easily configure the logging tools we are already using to log to syslog, a file, or whatever else, but the unanswered question of how we want to expose this capability within our app configuration.

Morgan is not really appropriate for our use case since it only logs HTTP requests. In addition to the fact that incoming HTTP requests are already being logged by the webserver, such a logger does not provide us the capability to log application specific error messages.

[lottspot]

I think that we need to expose the ability to set the logging backend via the configuration file, because if we containerize this application (a very real future possibility), I think retaining the ability to log to stdout would be extremely helpful. Such logging however is decidedly not helpful in antiquated init systems such as upstart. For those environments, having the capability to log to syslog or a flat file is important.

[lottspot]

I actually think this is important enough to block the completion of iteration 2