Comment 8 for bug 901498

Whats weird is that we separately have python logging glued onto the twisted logging in setup_tacfile_logging.

I think what we want is:
 - 'logging' messsages end up in logs
 - twistd messages end up in logs
 - exceptions from logging make oopses
 - exceptions from twistd code make oopses

seems like the /usual/ way to do this is to use the twisted logging layer so that twistd options work.

So:
 - setup_tacfile_logging gets us all the logging. calls. We must have this.
 - we should not forward twisted messages to python logging in general.
 - set_up_tacfile_logging is poor at the moment - it turns everything into a string and back again rather than translating it (e.g. to preserve backtraces as isError etc).
 - but the *default* for twistd is to capture stdout and stderr and respectively turn them into msg() and err() calls
 - so setup_tacfile_logging is entirely redundant if we have python logging writing to either stdout or stderr.
 - the default for python logging in the absence of any configuration is to output ERROR: lines on stderr.
 - if setLevel is called on the root logger, this will affect the default output

-> we should:
 - delete setup_tacfile_logging as no better than the default.
 - explicitly configure python logging to log to stdout only - no log files, no nothing. This will result in messages being caught by twistd's aggressive redirects.
 - *either* configure a logging OopsHandler (stdlib logging specific) -or- configure logging to send exceptions to stderr, to cause stderr exceptions to trigger oopses
 - configure the fallback observer for OopsObserver to be a UnixLogObserver or something similar.