Consistent format for debug/log messages

[agrover]

We should have a little bit of consistency in the format of these messages, since they will be included in the released product.

We need to come up with a format, apply it to all existing messages, and also document it in the design doc.

[mulkieran]

Content is at least as important as format. Identifiers which help sort out which thinpool, what filesystem, etc. are very important. It is really rough having to try to infer which item a message is most likely to be about based on preceding messages and hypotheses about changes in the call stack that might have occurred in between.

[agrover]

I think we may have to put up with some of that because right now we have layers that don't necessarily know e.g. the pool name of the pool they're operating on, but where possible I agree these should be included.

[mulkieran]

We have lot of functions that are very clear on the pool UUID, though, and could report that. That would really help us distinguish. The UUID is a persistent name (good!) but ugliish. The pool name is volatile, but pleasant in appearance. For a log entry, persistence is key.