perf(core): add an opt-in uncompressed IPC v1 mode

[jrschumacher]

Goal

Add a small, opt-in uncompressed IPC v1 mode while retaining the existing SDK, Connect protocol, and service contracts. Measure whether avoiding compression on in-memory calls reduces CPU, allocations, or latency before considering any default change.

Current behavior

The built-in IPC connection is assembled in service/internal/server/server.go (inProcessServer.Conn) using service/internal/server/memhttp. It uses in-memory pipes rather than TCP, but still performs Connect framing, protobuf serialization, and client/server interceptor work.

Two compression layers must be distinguished:

• Connect clients send identity-encoded requests by default but can negotiate gzip responses. The inspected Connect v1.19.2 default minimum compression threshold is zero.
• memhttp.Transport() does not set http2.Transport.DisableCompression, despite its current comment claiming automatic compression is disabled.

Disabling HTTP automatic compression alone does not disable Connect's own encoding negotiation. Also, sdk.WithExtraClientOptions(...) does not retrofit a supplied core connection, so this policy belongs at built-in IPC connection construction.

Relevant source: IPC connection, memhttp, SDK construction.

Proposed bounded change

• Add a new startup-only, default-off opt-in for the built-in IPC path; keep existing behavior when unset.
• When enabled, remove gzip from the IPC Connect client's response-compression negotiation and disable HTTP/2 automatic compression together. connect.WithAcceptCompression("gzip", nil, nil) is a candidate API; verify it against the implementation's pinned dependency.
• Leave remote SDK connections and caller-provided custom connections unchanged.
• Preserve IPC reauthentication, authorization, audit metadata, tracing, validation, message-size limits, deadlines/cancellation, and error semantics.
• Correct the misleading compression comments alongside the change.
• Document restart-based rollback to the existing mode.

Acceptance criteria

• Capture a reproducible baseline before tuning; compare small, medium, and larger representative payloads.
• Assert actual request and response encodings independently, including the unset/default mode.
• Record CPU/allocations/bytes and latency measurements; do not infer percentile latency from mean benchmark ns/op.
• Prove response/status equivalence and unchanged security, metadata, limits, and cancellation behavior.
• Verify remote and custom-connection paths remain unchanged.
• Add the startup opt-in and its tests in the same bounded PR; the flag does not exist today.
• Document results honestly, including no gain or regressions if observed; changing the default requires a separate decision.

Impact and rollout

Flag	Assessment
Requires downstream source changes	Normally no for standard built-in IPC after baseline dependency compatibility; conditional for custom SDK/connection wrappers
Configuration/deployment coordination	Required to opt in and restart
Feature flag supported today	No — introducing the gate is a merge requirement
High complexity	No, provided scope stays at IPC compression and characterization
High coupling	Conditional: shared IPC connection behavior requires parity coverage

Non-goals

No direct dispatch, serialization elimination, remote compression redesign, service logic changes, or claimed speedup before measurement.

Related: #2520. This is narrower than adding generalized service-owned SDK construction. Roadmap reference: ROAD-S09, with baseline characterization from ROAD-S06.

V1 release classification

Parent: #3996. Class: post-v1. Score: 1/10 (correctness/reliability 0/3; compatibility 0/3; operability 1/2; explicit v1 dependency 0/2).

No measured v1 performance requirement is currently established. The benchmark/diagnostic benefit is useful, but the existing transport remains the default. These scores measure release necessity, not potential value. Reclassify only when evidence ties the work to an agreed v1 requirement. The experiment's own parity/rollout acceptance criteria do not, by themselves, make the experiment a v1 release gate.