init upgrade submodule

[yoshuawuyts]

Initializes the "upgrade" submodule.

[yoshuawuyts]

Ref: bootstrapping websockets over h2 -- this is an example of how handshakes are done.

[yoshuawuyts]

The way this is intended to be used is:

1. client makes a request that includes details to what it wants to upgrade to
2. an http backend parser (e.g. async-h1) takes ownership of the sender from send_upgrade
3. some endpoint (e.g. in tide) takes ownership of the upgrade receiver from recv_upgrade and moves it into a task
   • inside the task it should wait for the connection to be passed
4. that same endpoint then returns the right portion of the server to indicate it's successfully upgraded
5. [missing] the http backend parser checks whether an upgrade is in progress.
6. the http backend parser sends through the response in full
7. if an upgrade was found to be have been requested, the http backend parser then sends through the connection to the endpoint using the upgrade sender obtained earlier
8. the endpoint is now operating on an upgraded connection and can speak the new protocol

[yoshuawuyts]

Okay, made a mistake. The upgrade sender / receiver needs to live on Response. That way we can add an is_upgrading method to Response that checks whether the upgrade::Receiver has been taken and the backend can decide to then send over the connection. This would resolve point 5 in my previous comment.

[yoshuawuyts]

@dignifiedquire even with the patch merged we're still having issues:

Tested by running cargo check --features unstable. I think I might have forgotten to add this to CI.

[yoshuawuyts]

Okay, we still need to move this to Response. Let's prioritize this for http-types 2.1.0.

[yoshuawuyts]

Okay, moved the logic to Response and added a has_upgrade method that returns whether we're upgrading. Everything in this patch is marked as "unstable" and by merging it now we can start experimenting with integrations into async-h1 and Tide. Going to go ahead and merge. Thanks!