Provide mechanism to share logger output locations

[nmiyake]

witchcraft-go-server has a notion of logging and is opinionated on output -- it decides on the io.Writer to use for writing logs based on factors such as configuration (useConsoleLog) and environment (isDocker or isJail), and when it performs file-based logging it does so using a lumberjack.Logger.

In some instances, a program may want to perform logging before the witchcraft.Server is created or started, but still wants to log in the same manner that the server would.

In order to do so, I propose the following:

1. Define a new FileWriterProvider interface that, given a path, returns an io.Writer that writes to that path
2. Define a LumberjackFileWriterProvider implementation that returns a lumberjack.Logger as it is currently defined in newDefaultLogOutput
3. Define a CreateLogWriter(logOutputPath string, logToStdout bool, stdoutWriter io.Writer, fileWriterProvider FileWriterProvider) io.Writer function
4. Add a WithFileWriterProvider(FileWriterProvider) function to the builder for witchcraft.Server (if not specified, it will use the LumberjackFileWriterProvider by default)

These primitives provide a general way to do a few things:

• It makes it possible to configure the file output writer in code. Right now, a file writer is hard-coded to be a lumberjack.Logger with a specific set of parameters. This change would allow file writers to be customized at a code level.
• With the above, a client can provide an implementation of FileWriterProvider that caches results and returns the same instance of a *lumberjack.Logger for a given path
  • This means that multiple loggers can be instantiated with the same lumberjack logger, and will thus not need to worry about overwriting each other
• With the above, a client can use CreateLogWriter to get the io.Writer that is appropriate for their environment/setup (log to stdout based on environment, etc.)

The only real downside I see is that this does expose a vector for customizing the file-based log output location that did not previously exist. However, this configuration point is purely in code (not in end-user configuration), so I don't think it's a huge risk.

If we really wanted to be stringent about this we could modify the FileWriterProvider API to more targeted (for example, only allow it to return a lumberjack.Logger and always override portions of that config after it is returned), but I think that's overkill and is over-fitting the specific problem trying to be solved here.