server: make the element-memory decode budget configurable

[iainmcgin]

Summary

buffa 0.9 bounds the memory a single decode may commit to repeated, map, string and bytes elements, defaulting to 32 MiB. It is charged on element footprint rather than contents, which is what makes it catch the amplification a size limit cannot: a few bytes on the wire can ask the decoder to materialize a very large number of small elements, each with its own allocation. A single large payload is unaffected however big it grows.

Since #233 that budget has reached every received request as a constant. A peer that legitimately sends many small elements — and that 0.8 accepted — is rejected, and there is nothing an operator can do about it. This makes it configuration.

ConnectRpcService::new(router)
    .with_limits(Limits::default().element_memory_limit(128 * 1024 * 1024))

Limits::unlimited() lifts it along with the other two.

Both decode paths, not just the obvious one

The value travels to the decoder on RequestContext for the view paths and on Payload for the owned-message ones.

The second half is the part worth reviewing. Generated dispatch is view-based throughout, so threading only decode_borrowed_request_view and decode_message_request_stream looks complete and passes every test. But Router::route_unary and the *_handler_fn registrations decode through Payload::take_message and decode_request, and those would have kept buffa's default silently — on exactly the handlers where a fully materialized owned message costs most. Payload carries the limits so its public take_message signature is unchanged.

The rejection says what to do about it

invalid_argument: failed to decode proto request: element memory limit exceeded; if this peer is trusted, raise Limits::element_memory_limit

Exceeding the budget is the one decode failure a server operator can fix without the peer changing anything, so it names the limit. Every other DecodeError keeps the bare message — pointing at a limit there would send someone chasing a setting that cannot help. A test pins both directions.

Breaking, for generated code only

decode_borrowed_request_view and decode_message_request_stream take the decode limits. Both are #[doc(hidden)] and called only from generated dispatch, so regenerating is the whole migration — which 0.9.0 already requires for buffa 0.9. Doing it now costs nothing; doing it later costs a second forced regeneration.

Limits also becomes #[non_exhaustive], so the next limit is not another break. Struct-literal construction becomes Limits::default().max_request_body_size(a).max_message_size(b); fields stay public for reads.

Incidental: the generated-code check was missing two directories

CI diffed four generated directories, CONTRIBUTING listed five, and there are six. connectrpc-health/src/generated and connectrpc-reflection/src/generated were unverified — and this change regenerates both, so the gap was live rather than theoretical. The check now covers all six and the doc is corrected.

Not in scope

Clients still decode responses under buffa's defaults, with no override. The server is where the budget bites first, so this ships server-only; the Limits docs now say so rather than leaving the asymmetry to be discovered.

Testing

Clippy on the pinned 1.95 toolchain, cargo test -p connectrpc --no-default-features (419), 56 test suites, lint, docs, server conformance 3600/0, and task generate:all regenerated with the CI-pinned protoc 33.5 / buf 1.69.0 and verified idempotent by hashing every generated file across two runs.

Driven live over a socket against a generated service with a repeated field, two servers differing only in this limit: default returns HTTP 400 naming the knob, element_memory_limit(usize::MAX) returns HTTP 200. The unit tests assert both halves too — rejected at the default, accepted when raised — so wiring the limit to nothing cannot pass.