Add filters for emitting Tracing diagnostics

[hawkw]

The tracing crate and related libraries provide an interface for Rust
libraries and applications to emit and consume structured, contextual,
and async-aware diagnostic information. tracing is maintained by the
Tokio project and is becoming widely adopted by other libraries in the
stack Warp uses, such as hyper, h2, and tonic and in other
parts of the broader Rust ecosystem.

This PR provides a new warp::trace module with filters to be used
when instrumenting Warp applications with tracing. This has to be
implemented inside of warp, because correctly instrumenting futures
with tracing spans requires the ability to wrap the future returned
by the inner filter. This branch is based on my PR #655, which migrates
Warp's internal diagnostics to Tracing.

This branch builds on the work done by @barskern in #408. I've updated
his branch to be based on the latest Warp master, added the convenience
filter for naming routes, example, and improved documentation from [my
initial attempt][1] at adding Tracing support to Warp, and made some
tweaks to the formatting of the generated traces and the user-facing
API. But, an equal amount of the credit goes to @barskern! <3

Here's some sample output from the tracing example:

Closes #288
Depends on #655

Co-authored-by: Ole Martin Ruud [email protected]
Signed-off-by: Eliza Weisman [email protected]

[seanmonstar]

I merged #655, which looks like this was based on. Mind rebasing master with this?

[hawkw]

@seanmonstar should be good now, I think?

[hawkw]

@seanmonstar okay, I fixed the mismatched targets, and also made a couple more tweaks to hopefully get more readable logs from the default warp::trace::request() filter. The user-agent string and request headers are now in a debug event inside the request span, rather than added to the span context, as they make every log line incredibly long:

Hopefully you folks agree that this is more usable?

[seanmonstar]

Yes, that's a nice improvement! Looking again, perhaps the user-agent shouldn't be included separately if the full headers are also included, because then it appears twice.

[hawkw]

Yes, that's a nice improvement! Looking again, perhaps the user-agent shouldn't be included separately if the full headers are also included, because then it appears twice.

Good call --- fixed it!

[jakajancar]

Is it intentional that the log level (INFO/WARN/ERROR) is determined based on whether the result is Ok or a Err(Rejection)?

I would expect that if a filter returns an explicit reply (*) with 4xx or 5xx, this should still be logged as WARN/ERROR respectively, same as built-in known rejections that result in 4xx/5xx.

(*) such as when adhering to "not all errors are rejections" philosophy