[Feature] Extended maxContentLength for Netty

[kciesielski]

This ticket describes one of the tasks of #2971

We want to extend our Netty-based servers to support checking for maxContentLength in requests on multiple levels. The implementation should prevent loading excessive bytes into memory:

1. Globally - as currently available in NettyConfig.maxContentLength.

• Current implementation for non-streaming servers uses HttpObjectAggregator which takes this as a parameter.
• The Cats Effect implementation has a different pipeline, using HttpStreamsServerHandler to produce reactive Publisher, which gets converted to a fs2.Stream in NettyCatsRequestBody. Here we should add a custom fs2 stage in the toStream() method; this stage would fail the stream if max content length is exceeded.
• The ZIO implementation is currently non-streaming, but ultimately it should become similar to the Cats Effect one, with a similar solution.

2. Per-endpoint - this can be carried by an endpoint attribute, which could be translated by the server interpreter to a ServerRequest attribute.

• The Future-based server would need to stop using HttpObjectAggegator and switch to HttpStreamsServerHandler, just like for the streaming servers (CE/ZIO). Then, its NettyRequestBody implementation would need to handle streams instead of ByteBuf. Otherwise it would be too late to prevent loading bytes into memory, which happens in HttpObjectAggregator. The new implementation of NettyRequestBody would need to handle a Publisher, using a custom Subscriber (see SimpleSubscriber in sttp for example). This subscriber would be responsible for pulling all the bytes and emitting a final byte array or fail in case of exceeded limit.

It would be great to be able errors properly, by emitting a HTTP 413 Entity Too Large response.