Triple http limiting the size of the HTTP request and response

[finefuture]

What is the purpose of the change

refer: #14068

1. When an HttpStatusException occurs during serialization, It does not need to be wrapped as an EncodeException
2. Use LimitedByteBufOutputStream to limit the size of the write data. Throws an HttpOverPayloadException when the limit is exceeded
3. Fix some typos

For example:

        tripleProtocol.setTriple(TripleBuilder.newBuilder()
                .maxBodySize(50)
                .maxResponseBodySize(100)
                .build());

Success result:

Request body limit result:

Response body limit result:

Brief changelog

Verifying this change

Checklist

• Make sure there is a GitHub_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GitHub issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
• Each commit in the pull request should have a meaningful subject line and body.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Check if is necessary to patch to Dubbo 3 if you are work on Dubbo 2.7
• Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
• Add some description to dubbo-website project if you are requesting to add a feature.
• GitHub Actions works fine on your own branch.
• If this contribution is large, please follow the Software Donation Guide.

[finefuture]

@oxsean PTAL

[oxsean]

I think h2 respone also need limit respone size.

[finefuture]

In http2:

1. In case of serialization failure, add tri-status and tri-message in trailers to indicate the reason for failure, and keep the header code as 200, or serialize first and then send the header frame for unary calls?
2. Can content-length be placed in trailers? Is it necessary to place it? Or provide configuration to write content-length?

[finefuture]

A problem encountered is that errors may occur during serialization. At this time, if the header is written first, the status code will be 200, but the result is failure.
Since both http1 and http2 currently only have unary calls, we can write the header after serialization is complete, which senses that serialization failed and returns a code of 500.

[finefuture]

Http2 no longer requires a content-length header, but some clients may use content-length to determine whether the data stream is complete. Therefore, refer to some common implementations in the industry to decide whether to add a content-length header to the http2 trailers, such as spring boot, tomcat, etc.

[finefuture]

New results
http2:

http1:

[oxsean]

LGTM.

[AlbumenJ]

@EarthChen PTAL

[EarthChen]

LGTM

[sonarcloud]

Quality Gate passed

Issues
4 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
1.2% Duplication on New Code

See analysis details on SonarCloud