MaxContentLength support (streaming)

[kciesielski]

Started as a solution to #3056 for Netty, but addresses more backends in general.
This PR introduces a possibility to add a MaxContentLength attribute to any endpoint. When set, decoding RequestBody in supported backends prevents loading too much into memory, and fails if the limit is exceeded.
As a result, DefaultExceptionHandler returns HTTP 413 Payload Too Large.

Streaming only
This is only a part of the full feature. The PR covers streaming support for streaming request body, excluding:

• Armeria streams
• Vertx streams
• zio1 streams

In a follow-up PR, I'll add:

• Support for non-streaming body (direct byte arrays, files)
• Documentation
• API extension to allow writing endpoint.maxContentLength(x) instead of setting an attribute.

[kciesielski]

@Mergifyio update

[mergify]

update

✅ Branch has been successfully updated

[adamw]

TODO ?:)

[adamw]

It seems there's a half-done maxContentLegth implementation for netty, in NettyServerHandler, plus a test in ServerBasicTests, which is only enabled for netty, though. Would be good to clean this up in the next PR as well :)

[adamw]

that's for the next PRs?

[kciesielski]

Yes, coming soon :) #3337

[adamw]

Nice (& tedious) work, thanks :)

[kciesielski]

It seems there's a half-done maxContentLegth implementation for netty, in NettyServerHandler, plus a test in ServerBasicTests, which is only enabled for netty, though. Would be good to clean this up in the next PR as well :)

That current netty-specific maxContentLength support is actually an interesting problem to discuss. It's

1. global, not per endpoint
2. affects both responses and requests
3. does not work for streaming

If we remove it entirely in favor of the new per-endpoint solution, we will lose features of 1) global scope 2) limiting response body.
If we keep it, it may be confusing to understand why there are 2 ways of setting max content length for Netty. Maybe we should limit it to responses only? Or deprecate it and observe who complains that they actually wanted 1 and 2, and not a per-endpoint request limiting?

[adamw]

Ideally, we want both: a global setting in ServerOptions, with a per-endpoint override (including disabling the global value). Though you can always map over all server endpoints and add the attribute, so maybe that's not needed 🤔

But we should definitely have one solution, so let's keep the "new" one only. I can't see limiting response size as a useful feature (you can do it in the business logic anyway)