ext_proc: filter ignores failure_mode_allow when ProcessorClientImpl::start() fails to create the gRPC client

[omkhar]

Summary

ProcessorClientImpl::start() in source/extensions/filters/common/ext_proc/grpc_client_impl.h returns nullptr without invoking onGrpcError or onGrpcClose when getOrCreateRawAsyncClientWithHashKey() returns an error (e.g. cluster lookup failure, raw async-client construction failure). The downstream Filter::openStream() in source/extensions/filters/http/ext_proc/ext_proc.cc treats stream_object == nullptr with no prior callback as IgnoreError and short-circuits the request through — regardless of the operator's failure_mode_allow setting.

Net effect: any failure_mode_allow=false deployment silently fails open on client-creation errors instead of rejecting the request as configured.

Filed in the open per maintainer redirect

Originally reported privately via GHSA-jp7j-jw2q-9494. @yanjunxiang-google closed the advisory and asked for this to land in the open as a regular bug fix since the issue is not externally exploitable (only fires on operator-side configuration errors).

Reproduction

1. Configure ext_proc filter with failure_mode_allow: false.
2. Point ext_proc at a non-existent cluster (or any config that causes getOrCreateRawAsyncClientWithHashKey() to error).
3. Send a request through the filter.
4. Expected: request rejected per failure_mode_allow=false.
5. Actual: request admitted (filter silently continues).

Proposed fix

PR forthcoming. Adds callbacks.onGrpcError(Internal, ...) on the failure branch in ProcessorClientImpl::start(), gated behind envoy.reloadable_features.ext_proc_report_client_creation_error (default true) per CONTRIBUTING.md guidance for user-visible protocol-processing changes.

[omkhar]

Duplicate of #45188 (more detailed, filed first). Closing in favor of #45188; PR #45189 will close that one on merge.