Logging Levels

Nobody has claimed this yet.

I'm doing some debugging and realizing that my logging is pretty disorganized right now. Writing down my thoughts here.

The good:
- I'm using glog everywhere, so at least that piece is standardized.
- Up until now the logging has been sufficient to help me debug a lot of issues.

The bad:
1. I'm debugging more complex tests, so now the debug info is too verbose, and I haven't made use of glog's verbosity support anywhere
2. Some common log string patterns like "peer doing something here" are hardcoded

For 1, I'm thinking about setting the following conventions for go-PPSPP:

- Level 0: Protocol API events (e.g. send HAVE, recv DATA, etc) and warnings (although I've read a good argument that [warnings are not something you want to lean on](https://dave.cheney.net/2015/11/05/lets-talk-about-logging))
- Level 1: Detailed logging that we want to keep in the codebase
- Level 2: Any other logging that you're not sure you want to keep around -- it's just useful for a very specific bug or test you're working on.

So the flow might be that while I'm debugging, I create a bunch of level 2 calls. Then when cleaning up a PR, I look at all my level 2 calls and promote some to level 1 and discard the rest.

For 2, I'm planning to create some convenience functions for pretty and relevant log message formats. For example, ppspp might implement an Infof function that automatically prefixes every message with the ID of this peer.

...

I'm going to try to fix these things as I debug my current tests in the complextest branch.
I made all this up after thinking about it for a few minutes. I'm very open to thoughts here.

The issue names glog and the complextest branch but no files or tests. Read the existing logging calls and compare them with the proposed verbosity levels and peer-prefixed helpers; done would require an agreed convention and implementation scope.

Written by the indexing model from the issue text.