feat:add limit for a maximum incoming connections

[jakubno]

---

Note

Medium Risk
Touches core request routing in the shared proxy and introduces request blocking behavior (429) based on runtime feature flags, so misconfiguration or limiter bugs could cause unexpected traffic drops.

Overview
Adds a feature-flag-controlled per-sandbox cap on concurrent incoming HTTP proxy requests; when the limit is exceeded, the proxy returns a dedicated 429 Too Many Requests templated error response.

This wires a shared connlimit.ConnectionLimiter into the shared reverse proxy handler (with acquire/release timing and blocked counters), adds new ingress-proxy telemetry histograms/counters, updates orchestrator startup/tests to pass feature flags and clean up limiter state on sandbox removal, and refactors TCP firewall to reuse the shared limiter implementation.

^{Written by Cursor Bugbot for commit bee88b7. This will update automatically on new commits. Configure here.}

[linear]

ENG-3488 Limit number of incoming requests to the sandbox

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 14a37c8b3e

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[dobrac]

add please also a histogram metric (same as egress firewall connections per sandbox) + the duration

[ValentaTomas]

Can this limiting be implemented by using the MaxConnsPerHost on the http.Transport in the https://github.com/e2b-dev/infra/blob/feat/limit-number-of-incoming-requests-to-the-sandbox-eng-3488/packages/shared/pkg/proxy/pool/client.go?

The only disadvantage I see is that this way of limitation would block when we reach the limit, which means that we would still keep the connection around on the client proxy and we won't be able to quickly return appropriate error.

[ValentaTomas]

Also, for clarity, thinking about actually returning https://http.dev/509