feat: make ext_proc circuit breaker max_requests configurable via Helm

[PatilHrushikesh]

Description

The default Envoy circuit breaker max_requests of 1024 causes gRPC overflow errors
(ext_proc_error_gRPC_error_14{...overflow}) when many concurrent requests open gRPC
streams to the ext_proc server simultaneously.

This makes the ext_proc UDS cluster circuit breaker max_requests configurable via the
--extProcMaxRequests controller flag, exposed through the Helm chart as
controller.extProcMaxRequests. The default remains 1024, matching Envoy's built-in default.

The extensionserver.New() function signature changed to accept the new extProcMaxRequests uint32
parameter.

Related Issues/PRs (if applicable)
N/A
Special notes for reviewers (if applicable)
N/A

[nacx]

Is this getter needed? The logic in this getter is already handled in hte constructor.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 84.43%. Comparing base (edef4c5) to head (f60a1e5).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1884   +/-   ##
=======================================
  Coverage   84.42%   84.43%           
=======================================
  Files         134      134           
  Lines       19162    19174   +12     
=======================================
+ Hits        16177    16189   +12     
  Misses       1998     1998           
  Partials      987      987           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[nacx]

Can you take a look at the failing tests?

[PatilHrushikesh]

/retest

[PatilHrushikesh]

/retest

[mathetake]

why don't you just set MAXINT32 instead of adding an option? The limit could be effectively applied on the downstream/upstream side config instead of at extrproc

[PatilHrushikesh]

why don't you just set MAXINT32 instead of adding an option? The limit could be effectively applied on the downstream/upstream side config instead of at extrproc

This can also be done, but this will bring back upgrade failure issue, where after upgrade is cluster configuration is different which causes CDS update and streaming requests in progress are dropped by extproc

[PatilHrushikesh]

/retest