Provide support for subgraph connections to only be made with h2c (http2 cleartext/prior knowledge)

[theJC]

Describe the solution you'd like
In subgraph_service.rs provide explicit support allowing configuration of router to result in all outbound subgraph connections to be made using http2 cleartext (h2c). Due to using h2c, there is no need to initialize the tls_config setup for these connections at all.

Additional context
Our environment's service to service communication uses envoy. Each service's outbound connections connect via h2c to its own envoy sidecar. That envoy sidecar provides load balancing and cross datacenter failover capabilities and establishes http2/tls connections to all destination service instances envoy sidecars which then communicate with the destination service's ingress h2c endpoint listener. Thus for router to exist and communicate using the approved/golden path used by services, we need to be able to tell router to only use h2c for its outbound connections to subgraphs.

https://docs.rs/hyper/latest/hyper/client/struct.Builder.html#method.http2_only
we have used tonic to make grpc calls over service mesh, and that requires h2c - and tonic is built on hyper

In Apollo Gateway which we are working to migration off of, we have been using h2c outbound and accomplished this via the fetcher interface on RemoteGraphQLDataSource and used @adobe/fetch.

[theJC]

Got a POC code change in a branch to prove it is functional and working/using h2c to communicate with subgraphs -- no frills version that doesn't have configuration control over http1 vs http2 cleartext/prior-knowledge is used -- I just commented out the use of hyper_rustls and used hyper::Client just to prove it works.

theJC@fa00f4d

[abernix]

@theJC That's good to hear! Out of curiosity, in the side-car configuration, do you find that this improves performance over HTTP1 because of less connections between the Router and the sidecar? (I haven't thought extensively about it, just curious to understand motivations and the overall success metrics better.)

Beyond to my inquisition though, would you be interested in proposing a set of configuration file changes that would map well to accommodating this customization? Maybe this could turn into a PR/contribution if we agree on the design/format?

[theJC]

@abernix -

My understanding of the h2c over http1 benefit at play for us:

• Improves resource utilization of both services and their underlying not maintaining the http1.1 connections
• Envoy's native representation is much closer to http2, so http1 codecs have to spend additional effort translating into aligning to that underlying representation
• limits in place on the number of http1 connections so that can cause delay cause waits on connections to free up before the are able to be re-used for the next request
• of course there is the http2 benefits talking points including header compression, etc

Id be glad to collaborate/propose what I envision what the configuration file could look like to support this, as far as an PR I definitely dont have my Rust skills up to snuff to the point where you would welcome a PR from me quite yet -- to get my POC above I commented out, changed a couple things and then figured out what broke/what errors and brute forced them until they worked ;) I believe someone who knows what there doing in Rust, especially router, will be able to get this done 100 times faster at this point.

[theJC]

My first initial proposal I think would be something like this...

tls:
  subgraph:
    all:
      enable: false

traffic_shaping:
  subgraphs:
    all:
      http2:
        enable: true     ## was: experimental_enable_http2: true -- default value
      http1:
        enable: false    ## default true