client: add --grpc-mode unary for gRPC load with grpc-status scoring

[bpalermo]

Description

This PR is related to #24

Adds --grpc-mode unary for gRPC unary load generation with grpc-status scoring. Nighthawk has no gRPC awareness today: a gRPC request had to be assembled by hand (framing, headers), and a failed RPC that comes back as HTTP 200 with grpc-status: 13 is counted as http_2xx because decodeTrailers() only keeps trailers for the tracing span.

--grpc-mode unary:

• Implies --protocol http2 (h2c prior knowledge on http:// URIs) and --request-method POST; sets content-type: application/grpc and te: trailers; no Content-Length.
• Wraps the --request-body-file bytes (one serialized protobuf message) in the gRPC length-prefixed frame, so users supply only the message. The method is the URI path, e.g. http://host:8080/pkg.Service/Method (a :path request header still overrides).
• Scoring: grpc-status is read from the trailers, or from the headers on trailers-only responses. Status 0 is a success and feeds the new benchmark_http_client.latency_grpc_ok statistic; any other or missing status increments benchmark.grpc_error and benchmark.grpc_status.<code> (.missing when absent) and is not counted as benchmark.http_2xx. HTTP-level counters and latency_* statistics keep their meaning, so non-gRPC runs are unaffected.
• Validation: requires HTTP/2 and POST; not combined with --request-source.

Notes for Reviewers

• Stacked on client: add --request-body-file to send a file's bytes as the request body #1601 (--request-body-file): only the last commit is new here; will be rebased once client: add --request-body-file to send a file's bytes as the request body #1601 merges.
• StreamDecoderCompletionCallback::onComplete() / exportLatency() gain the observed grpc-status; the response body is consumed and its size recorded as before.
• Testing: //test:stream_decoder_test (status from trailers, trailers-only, trailers override headers, none on plain HTTP), //test:benchmark_http_client_test (accounting per outcome and inert when off), //test:factories_test (headers, framing, no content-length), //test:options_test, test/integration/test_grpc_unary.py (runs against the test server with injected grpc-status, including a gRPC-aware Envoy's synthesized status and no status). Verified end to end against a grpc-java server (arm64) to 8k rps with zero errors. README usage regenerated; version history updated.
• --grpc-mode is an enum-valued flag (GrpcMode in options.proto); unary is the only value here and client: gRPC bidirectional streaming mode (--grpc-mode bidi-stream) #1603 adds bidi-stream, so streaming does not need a second boolean flag.
• Streaming is a follow-up (client: gRPC bidirectional streaming mode (--grpc-mode bidi-stream) #1603).

[eric846]

In case we don't have the cycles to review the gRPC PRs in the next weeks, I wanted to let you know about another option that might make it easier to work in the short term, at least for unary gRPC.

You might be able to:

• make your own in-process C++ RequestSource plugin similar to LlmRequestSource. You can control the content-type, directly set the body to any bytes as specified in your own config proto or generated in C++ on the fly, and set any other headers needed for gRPC. A RequestSource can send a different request every time.
• set HTTP2

Of course this approach would be missing the capability to inspect the gRPC response and update gRPC-specific counters.

[bpalermo]

In case we don't have the cycles to review the gRPC PRs in the next weeks, I wanted to let you know about another option that might make it easier to work in the short term, at least for unary gRPC.

You might be able to:

• make your own in-process C++ RequestSource plugin similar to LlmRequestSource. You can control the content-type, directly set the body to any bytes as specified in your own config proto or generated in C++ on the fly, and set any other headers needed for gRPC. A RequestSource can send a different request every time.
• set HTTP2

Of course this approach would be missing the capability to inspect the gRPC response and update gRPC-specific counters.

Appreciate, I will try it in the meanwhile, thanks!

fwiw I already have this working in a fork.