feat(timber): prettier logs

[EverlastingBugstopper]

this is a crack at #220 that gives us some prettier logs and also separates logging concerns from user-facing output concerns.

log usage is still the same, folks still pass --log <log-level>, and instead of tracing::info for user-facing output, we directly use eprintln.

log formatting is also a bit different and a bit more helpful for debugging than our previous formatting:

   reqwest::async_impl::client: response '200 OK' for https://graphql.api.apollographql.com/api/graphql, , , , 
    at /home/avery/.cargo/registry/src/github.com-1ecc6299db9ec823/reqwest-0.11.0/src/async_impl/client.rs:1477

   rover_client::blocking::client: response_status: 200, response_headers: {"x-powered-by": "Express", "vary": "Origin", "access-control-allow-credentials": "true", "access-control-expose-headers": "logged-in,identity", "strict-transport-security": "max-age=31536000; includeSubDomains", "logged-in": "true", "identity": "user:gh.EverlastingBugstopper", "content-type": "application/json; charset=utf-8", "content-length": "290", "etag": "W/\"122-ywmnv7flrpbtgXc02AmStpRls80\"", "date": "Fri, 19 Feb 2021 20:53:05 GMT", "via": "1.1 google", "alt-svc": "clear"}
    at crates/rover-client/src/blocking/client.rs:51

   rover_client::blocking::client: {"data":{"frontendUrlRoot":"https://studio.apollographql.com","service":{"implementingServices":{"__typename":"FederatedImplementingServices","services":[{"name":"people","url":"","updatedAt":"2020-12-18T18:25:44.844Z"},{"name":"films","url":"","updatedAt":"2020-12-18T18:26:10.961Z"}]}}}}

[EverlastingBugstopper]

comment out of date, see updated top level comment

perHAPS. perHAPS. We could just get around all of this by adding some sneaky eprintln!(" ") before our println statements in RoverStdout. This way output wouldn't get mangled if it was passed to another process AND the spacing of our output would align properly with the default info level logs, making things look much nicer.

[EverlastingBugstopper]

comment out of date, see updated top level comment

still not loving this. after some thought - maybe a better approach is more like this:

by default we do not print any tracing logs to stderr, and we convert all of our app-level user messages (that are currently tracing::info!) to eprintln! statements, and we persist all debug/trace level logs to the users filesystem as outlined in #239

if user is TTY and they pass -l debug or -l info, we print those level logs to stderr and not persist the logs on the file system.

I would assume then that it's OK to just leave user-facing eprintln level logs out of the actual logs altogether.

[lrlna]

If I remember correctly we were talking about timber eventually taking care of both logging with tracing crate and printing to stdout. I think your second comment saying that we should only print println/eprintln to the user makes a lot of sense if we end up going with that route in the future. If users are passing in --log=debug, we can just print the logs the way you have them formatted here (I think I'd even keep the source_location). And at that point, I don't think it matters too much that they are indented a bit to the right.

I wanted to also say that tracing_subscriber has a visitor that does all the padding (in case you haven't seen this already. If we really wanted to unify the padding situation, we can also write a small visitor of our own. I do think though if we are going to be using (even for just right now) only printlns to print out to the user including everything that's currently done by tracing::info, we can live with logs being a tad indented. Would be happy to hear your thoughts on this though!

[lrlna]

If we (the rover team) are debugging-debugging, I think the source_location is pretty useful. Let's keep it!

[lrlna]

By the way, I think this is more of stab at #220!