Support for gRPC client streaming

[jumaffre]

Same as https://github.com/microsoft/CCF/issues/4325, but the other way around.

The tricky part is that we cannot yield (i.e. it's blocking!) from the endpoint handler until more messages from the client are available for reading, although we should be able to provide the same programming model as for the C++ gRPC library (see https://grpc.io/docs/languages/cpp/basics/#streaming-rpcs).

[jumaffre]

As discussed with @eddyashton, this is a significant chunk of work that doesn't seem absolutely necessary for external executor support right now, so probably not as urgent for 4.x as other items. This is significant because there's no way to identify early (i.e. HTTP/2 layer) whether an endpoint will support client streaming, and so the frontend logic needs to be changed for all request types (e.g. unary and streaming).

In particular:

• Because we cannot block/hold an entire thread while waiting for further client messages, the endpoint handler should be called for every fully-formed gRPC message received from the client.
• The frontend execution should start when all the headers have been received (rather than only when the NGHTTP2_FLAG_END_STREAM is set on a header/data frame). This has many knock-on effects as the RpcContext, kv::Tx, etc. objects now have to be owned by the long-lived stream, rather than local variables in the process_command() function.
• It is the responsibility of the endpoint wrapper to find out whether the entire request body has been received (unary) or whether it can read as much as it needs from the incoming stream data (client streaming) before executing the handler.
• Whereas gRPC streams only call one endpoint, a single raw HTTP/2 stream may call different endpoints so the new logic should support different endpoints over the same stream.
• As a client-streaming endpoint may be long-lived, the incoming body data should probably be shrunk once it has successfully been read by the endpoint.

The investigation work is on this branch and currently supports a single client-streaming endpoint.

[jumaffre]

As discussed, in the meantime, we should write documentation to explain the behaviour if a client starts streaming requests to the server. The stream will currently hang as the NGHTTP2_FLAG_END_STREAM isn't sent by the client.

[jumaffre]

This work will be necessary to support gRPC apps, e.g. https://github.com/microsoft/LSKV.

[jumaffre]

See ccf_watches.path in https://github.com/microsoft/LSKV/pull/186 for a small patch to support this.