gRPC callouts: remove specialized hostcalls

[PiotrSikora]

Since gRPC it's built on top of HTTP, it's debatable whether we need a specialized hostcall for gRPC callouts or if SDKs could provide them themselves.

As far as I recall, we've added those because Envoy implemented them using grpc library that automatically authenticated service accounts on GCP, but I'm not sure if that's still needed? cc @kyessenov

[leonm1]

I think Envoy uses AsyncClientImpl for grpc, which is also the base for httpCall.

I think it'd be a bit challenging for the wasm module to handle grpc framing into an H2 stream on its own, especially since plain gRPC clients wouldn't be hooked up to the httpCall ABI function (and use raw socket operations instead). For prior art on this, the ext_proc filter for Envoy split out GRPC from HTTP streams due to the complexity of the framing.

[PiotrSikora]

I think it'd be a bit challenging for the wasm module to handle grpc framing into an H2 stream on its own, especially since plain gRPC clients wouldn't be hooked up to the httpCall ABI function (and use raw socket operations instead).

gRPC messages are length-prefixed, so the only special thing about handling them is that you need to buffer and de-frame complete gRPC messages before processing them at the gRPC level, but there is zero complexity there.

From: https://grpc.github.io/grpc/core/md_doc__p_r_o_t_o_c_o_l-_h_t_t_p2.html:

The repeated sequence of Length-Prefixed-Message items is delivered in DATA frames

Length-Prefixed-Message → Compressed-Flag Message-Length Message
**Compressed-Flag** → 0 / 1 ; encoded as 1 byte unsigned integer
Message-Length → {length of Message} ; encoded as 4 byte unsigned integer (big endian)
Message → *{binary octet}

Also, I couldn't find anything that would require lower-level access to HTTP/2 stream. Perhaps flushing of messages when sending, but that's not gRPC specific and perhaps worth a separate issue.

For prior art on this, the ext_proc filter for Envoy split out GRPC from HTTP streams due to the complexity of the framing.

This was added was because of ext_proc support in gRPC's xDS, specifically Payload Handling section, to avoid mixing gRPC application and transport layers.

But circling back to Proxy-Wasm, this boils down to whether we want to have a specialized support for gRPC or not, and where do we want to handle it, since removing this basically moves buffering and de-framing from host environments to SDKs.

Alternatively, we could go all-in on gRPC support and add support for "HTTP-unware" gRPC plugins that operate on the gRPC message level, using on_grpc_receive callbacks as the entry point. I believe this is what @gkhom was asking about a while ago, but I think our conclusion at the time was that we could do buffering and de-framing inside the SDKs.