Update to tracing 0.1.36

[kayabaNerve]

tracing 0.1.35 pulls in tracing-core 0.1.27 which adopted once_cell over lazy_static, fixing some macro issues I had when I tried to compile with minimal dependencies.

tracing 0.1.36 is explicitly guaranteed to compile with -Zminimal-versions. hyper-util explicitly does not compile against the minimal version of tracing 0.1 as it uses misc features added between 0.1 and 0.x. 0.1.36 is within hyper-util's MSRV bound.

This version of tracing is sufficient for all my experiments I did with -Zminimal-versions, hence why I PR it here, but I can't confirm this is sufficient for all environments, the exact latest version of hyper-util, and in the future, a workflow confirming hyper-util compiles with -Zminimal-versions would be valuable. I also encountered issues with how tower 0.4 wouldn't compile against tower-layer 0.3 (solely tower-layer 0.3.1), but tower is no longer an explicit dependency of hyper-util.

[seanmonstar]

Do we need to explicitly depend on this version? Unless we're using a new feature, I prefer to specify the oldest version we can, so that consumers can decide the actual version themselves in their lockfile.

[kayabaNerve]

I needed 0.1.35 for my usage to compile at all (and I do not depend on or utilize tracing myself). I chose 0.1.36 solely because they guarantee they fixed their own dependencies w.r.t. minimal-versions in the changelog entry for it. I didn't think the single patch version was worth the quibble when it resolves this exact intent.

The tokio 1.13 bound should be minimal.

[seanmonstar]

What I mean is, you can always run cargo update in your own project, and it will pick the newest versions of any dependencies. hyper-util doesn't need to do anything to enable that.

[kayabaNerve]

Yes, but if you run with cargo update -Zminimal-versions to run with the minimum supported versions, hyper-util fails to compile because it has incorrectly defined bounds. This means people who want to use the minimum possible dependencies, whether explicitly or solely to see what range of versions they could use, will instead be hit with compilation failures because hyper-util refuses to compile against its published dependency bounds.

This PR, effectively, corrects hyper-util to the minimum dependencies it will actually compile with. It maintains all user functionality, as you desire, without itself breaking when minimal versions are used, as a headache for everyone else. I had to state these minimum bounds in my software to compensate for how my dependent software inherits these bounds, but hyper-util didn't state them properly :/

[seanmonstar]

Got it, that's what I was wondering, thanks!

[kayabaNerve]

Thanks! One less bother for me. Also, I'm sure it's an obvious comment, but thanks for all your work on HTTP in the Rust ecosystem. I'm much appreciative :)