Investigate feasibility of Hyper 1.0 usage for invoker

[slinkydeveloper]

I've identified the components we need to implement this migration:

Client

• The connection pool. I think for that we can reuse the pool in hyper-util https://github.com/hyperium/hyper-util/blob/3c37c5ba62780cf593f53ce2fcb3e7c312eb95d6/src/client/pool.rs. It has a generic over the key, which allows us to generify the connections based on invocation-key as well.
  • Make sure we can connect with two tcp connections to same endpoint?
  • Do we need to support HTTP/1? Or could we just reduce the scope of the invoker to HTTP/2?
• HTTP Connector, that is the component that creates a new TCP/TLS connection when needed. We can use again what is available in hyper-util https://github.com/hyperium/hyper-util/blob/master/src/client/connect/http.rs but keep in mind that this won't work with HTTP(s). Perhaps we can manually use the connector provided by https://github.com/rustls/hyper-rustls, see https://github.com/rustls/hyper-rustls/pull/192
• Some glue code that tries to grab a connection from the connection pool, and if not possible it uses the HTTP connector to create a new one, and then register it to the pool. We can take and adapt most of the code from legacy.rs Client::send_request and Client::connect.

Body

Body::sender has been removed. We can use StreamBody from http-body-util to send and receive streaming bodies, or implement ourselves our own body, since the trait has been simplified and should be easier to implement one now.

[tillrohrmann]

Do we need to support HTTP/1? Or could we just reduce the scope of the invoker to HTTP/2?

Will the lambda service endpoint work with HTTP/2? If yes, then one thing I could imagine where HTTP/1 might be useful is if someone wants to implement a SDK w/ it (because request/response mode is simpler or so?).

[slinkydeveloper]

Will the lambda service endpoint work with HTTP/2?

Yes, because the users puts the AWS API gateway in front of it, which supports HTTP/2 prior knowledge and ALPN, so no issues there.

HTTP/1 might be useful is if someone wants to implement a SDK w/ it (because request/response mode is simpler or so?).

The invoker doesn't imply that HTTP/2 means bidi-stream support, it picks the service protocol "mode" based on the configuration and not on the established connection.

I would say let's implement HTTP/1 only if we need it. I think it's safe to assume that communications between internal systems out there today can do HTTP/2.

[slinkydeveloper]

I think for the time being we agree to stay on hyper, and eventually adopt 1.0 when possible. I'll close this issue for the time being as I consider the investigation done.