executor: switch from log to tracing (#1454)

## Motivation

The `tracing` crate implements scoped, structured, context-aware
diagnostics, which can add significant debugging value over unstructured
log messages. `tracing` is part of the Tokio project. As part of the
`tokio` 0.2 changes, I thought it would be good to move over from `log`
to `tracing` in the tokio runtime. Updating the executor crate is an obvious
starting point. 

## Solution

This branch replaces the use of `log` in `tokio-executor` with
`tracing`. I've tried to leave all the instrumentation points more or
less the same, but modified to use structured fields instead of string
interpolation. I've also added a few `tracing` spans, primarily in
places where a variable is added to all the log messages in a scope.

## Notes

For users who are using the legacy `log` output, there is a feature flag
to enable `log` support in `tracing`. I thought about making this on by
default, but that would also enable the `tracing` dependency by default,
and it is only pulled in when the `threadpool` feature flag is enabled.
The `tokio` crate could enable the log feature in its default features
instead, since the threadpool feature is on by default in `tokio`. If
this isn't the right approach, I can change how `log` back-compatibility
is enabled.

We might want to consider adding more `tracing` spans in the threadpool
later. This could be useful for profiling, and for helping users debug
the way their applications interact with the executor. This branch is
just intended as a starting point so that we can begin emitting
`tracing` data from the executor; we should revisit what instrumentation
should be exposed, as well.

Signed-off-by: Eliza Weisman <[email protected]>

tokio-executor/src/threadpool/task/mod.rs

@@ -9,11 +9,10 @@ use super::pool::Pool;
 use super::waker::Waker;
 
 use futures_util::task;
-use log::trace;
 use std::cell::{Cell, UnsafeCell};
 use std::future::Future;
 use std::pin::Pin;
-use std::sync::atomic::Ordering::{AcqRel, Acquire, Relaxed, Release};
+use std::sync::atomic::Ordering::{AcqRel, Acquire, Release};
 use std::sync::atomic::{AtomicPtr, AtomicUsize};
 use std::sync::Arc;
 use std::task::{Context, Poll};
@@ -95,8 +94,13 @@ impl Task {
 
     /// Execute the task returning `Run::Schedule` if the task needs to be
     /// scheduled again.
+    ///
+    // tracing macro expansion adds enough branches to make clippy angry here.
+    #[allow(clippy::cognitive_complexity)]
     pub(crate) fn run(me: &Arc<Task>, pool: &Arc<Pool>) -> Run {
         use self::State::*;
+        #[cfg(feature = "tracing")]
+        use std::sync::atomic::Ordering::Relaxed;
 
         // Transition task to running state. At this point, the task must be
         // scheduled.
@@ -109,8 +113,10 @@ impl Task {
             Scheduled => {}
             _ => panic!("unexpected task state; {:?}", actual),
         }
+        let span = trace_span!("Task::run");
+        let _enter = span.enter();
 
-        trace!("Task::run; state={:?}", State::from(me.state.load(Relaxed)));
+        trace!(state = ?State::from(me.state.load(Relaxed)));
 
         // The transition to `Running` done above ensures that a lock on the
         // future has been obtained.
@@ -151,7 +157,7 @@ impl Task {
 
         match res {
             Ok(Poll::Ready(_)) | Err(_) => {
-                trace!("    -> task complete");
+                trace!("task complete");
 
                 // The future has completed. Drop it immediately to free
                 // resources and run drop handlers.
@@ -172,7 +178,7 @@ impl Task {
                 Run::Complete
             }
             Ok(Poll::Pending) => {
-                trace!("    -> not ready");
+                trace!("not ready");
 
                 // Attempt to transition from Running -> Idle, if successful,
                 // then the task does not need to be scheduled again. If the CAS