client: gRPC bidirectional streaming mode (--grpc-mode bidi-stream)

[bpalermo]

Description

This PR is related to #24

Adds --grpc-mode bidi-stream, gRPC bidirectional streaming load with per-message latency. It opens --streams long-lived bidi streams to the URI path (spread evenly over the workers) and sends the --request-body-file message on them at an aggregate --rps message rate, round-robin over the streams, on the sequencer's absolute schedule: late sends fire immediately and are never rescheduled, which keeps the run free of coordinated omission. The server is expected to echo one message per message, in order, on the same stream (gRPC guarantees per-stream ordering), so echoes are correlated FIFO per stream and the send-to-echo time of every message is recorded in benchmark_stream.message_latency.

A send scheduled for a stream that already has --max-inflight-per-stream unanswered messages (default 256), or whose write buffer is above Envoy's high watermark, is dropped and counted in benchmark.stream_deferred rather than queued, which makes that counter a clean saturation signal. At the end of the run every stream is half-closed and echoes are collected for --stream-drain-duration (default 0.5s) before the counters are snapshotted; the grpc-status of each closed stream lands in benchmark.stream_grpc_status.<code>, and streams still open when the window ends are counted in benchmark.stream_drain_incomplete with their unanswered messages in benchmark.stream_inflight_lost.

Other counters: benchmark.stream_messages_sent / stream_messages_received, streams_opened, stream_open_failures, stream_unavailable, stream_resets, stream_early_close, stream_unexpected_message, stream_write_blocked.

Notes for Reviewers

• Stacked on client: add --grpc-mode unary for gRPC load with grpc-status scoring #1602 (which is stacked on client: add --request-body-file to send a file's bytes as the request body #1601): only the last commit is new here; will be rebased as those merge.
• bidi-stream is the second value of the GrpcMode enum that client: add --grpc-mode unary for gRPC load with grpc-status scoring #1602 introduces with --grpc-mode unary, so streaming needs no separate boolean flag.
• Design: a new GrpcStreamBenchmarkClientImpl (source/client/grpc_stream_client_impl.*) owns the streams and implements BenchmarkClient; the existing sequencer, rate limiter and termination predicates drive it unchanged (tryStartRequest() sends one message and completes on its echo). Envoy's Grpc::Decoder reassembles echoed frames across DATA frames. BenchmarkClient gains prepare() (open the streams before the sequencer starts) and finish() (half-close and drain before the worker snapshots counters), both no-ops for the HTTP client.
• In this mode --rps is the aggregate message rate divided over the workers, --concurrency must be numeric and divide both --streams and --rps, and --max-pending-requests is raised to hold all of a worker's opening streams; --max-active-requests must cover the streams per worker. Not combined with --simple-warmup, request source plugins or user-defined output plugins.
• Testing: //test:grpc_stream_client_test with a mocked pool/encoder (sync and async opens, round-robin and echo completion with latency, frames split across DATA chunks, in-flight bound and write-watermark deferral, early server close, resets, half-close + drain, drain timeout and terminate); //test:options_test, //test:factories_test, //test:client_worker_test for the new hooks. Verified end to end against a grpc-java bidi echo service (arm64): 20 streams at 400 to 4,800 msg/s and 40 streams at 4,000 to 16,000 msg/s, every message echoed, zero deferred, all streams closed with grpc-status 0. README usage regenerated; version history updated.