Move support for `std::futures::Futures` into `tracing`

[davidbarsky]

Desired end state: tracing customers should be able to instrument/decorate std::future::Future (and by extension, asynchronous blocks, functions, and methods) by only taking a dependency on tracing instead of tracing + tracing_futures as they do now. These changes should be minimally intrusive and avoid a breaking release of tracing_futures if at all possible.

Introduction

Since std::future::Future is now in std, we can confidently movetracing_futures::Instrument and tracing_futures::Instrumented into tracing. The implementations for Executors, Sinks, and Streams should remain in tracing-futures until those traits (or the std) equivalent has landed in the stable release channel of Rust. This change is the correct thing to make for tracing’s customers as we've seen people trip over correctly instrumenting asynchronous code and moving Instrument into tracing allows us to increase the misuse resistance of tracing.

Assorted Implementation Notes

• The PR at [WIP] Start moving tracing_futures into tracing #611 should be completed.
• The Instrumented/Instrument trait should be implemented for stream, sinks, and executors. I'm not sure how to approach the implementation in a manner that abides by coherence rules, but I can think of two options:
  • I think—but am highly uncertain—that with the recent re-balancing coherence changes, it might be possible to maintain the existing implementations in tracing-futures.
  • Its more likely that we'd need to implement a (sealed?) extension trait of Instrumented for the Stream, Futures, and Executor implementations. This might be a breaking change.
• Instrumented/Instrument should be re-exported from tracing via tracing-futures.