Chore: Move OnUpgrade state from Body to Request/Response

[aknuds1]

Move OnUpgrade state from Body to http::Request/http::Response extensions.

Fixes #2340.

[aknuds1]

@seanmonstar I came up with a scheme that I think makes sense, storing OnUpgrade state in MessageHead::extensions and moving the state into Response::extensions and Request::extensions. I get a compilation error due to missing trait implementations for Extensions however, could you help me understand how to solve them please? Also, just point out if I should simply have solved it differently :)

✗ cargo build --all-features
   Compiling hyper v0.14.0-dev (/home/arve/Projects/hyper)
error[E0277]: the trait bound `Extensions: Clone` is not satisfied
  --> src/proto/mod.rs:29:5
   |
29 |     extensions: http::Extensions,
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Clone` is not implemented for `Extensions`
   |
   = note: required by `clone`
   = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0369]: binary operation `==` cannot be applied to type `Extensions`
  --> src/proto/mod.rs:29:5
   |
29 |     extensions: http::Extensions,
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0369]: binary operation `!=` cannot be applied to type `Extensions`
  --> src/proto/mod.rs:29:5
   |
29 |     extensions: http::Extensions,
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)

[seanmonstar]

Those are probably from derives on MessageHead. You can likely remove the ones that are causing a problem (Clone, PartialEq), I don't think they're used any more.

[aknuds1]

@seanmonstar Thanks, I thought those traits were necessary. Removed them, fixed the compile :)

[aknuds1]

I'll rebase to fix commit messages, since everything else looks fine.

[seanmonstar]

Fantastic work! This is exactly what I had in mind. Just one comment inline.

[aknuds1]

Thanks @seanmonstar! I applied your suggestion.

BTW, I amended into the original commit, and rebased. Do you prefer this way of working on PRs, or would you prefer if I avoid rewriting the commit history (i.e., just merge, add new commits)?