Fix HttpClientWithTomcatTest flaky test.

[pderop]

This is a new attempt to fix the flaky test from HttpClientWithTomcatTest.testIssue2825, which was still sometimes getting some Premature Close Exception.

To summarize:

• The fix from Request for read interest when channel is unwritable while HttpClient.send(Mono) is used #2864 significantly reduces the probability to get premature close exceptions when Tomcat sends an early final response 400 bad request while the client is still writing a large request body. Did a benchmark using a real network, it works well; no premature close exceptions.
• However, on localhost, and especially on the Github CI, the fix only alleviate the problem but we can't avoid it all the time: sometimes, once the server has sent the 400 bad request, and once it has read up to 2 MB of extra request body, it may then close the connection using a TCP/RST, so in this case, if the client has not yet consumed the 400 bad request, it may miss it (when receiving the TCP/RST, the client OS may drop any unread data).
• The test is now doing his best in order to let the client have time to consume the 400 bad request, and if you disable the patch, the test will reproduce the issue described in Misleading reactor.netty.http.client.PrematureCloseException: Connection prematurely closed BEFORE response #2825.

Did the following fixes:

• Fixed thePayloadSizeServlet which was not counting correctly the number of bytes received.
• Fixed test http request PAYLOAD size: when the max payload size is exceeded, the test should at least write some extra bytes >= 2 MB, which is the value for maxSwallowSize on Tomcat. Else, the test would pass even without applying the fix from Request for read interest when channel is unwritable while HttpClient.send(Mono) is used #2864
• Reduce the SO_RCVBUF on the Tomcat server, to reduce the possibility that the client is writing while the server is closing the connection (with a small Tomcat SO_RCVBUF, the client will likely be blocked on socket writing while the server is closing the connection.
• To avoid racy situation when the client can't read the response before the socket is closed with a TCP/RST or when the client is getting a broken pipe while writing, the testIssue2825 is now using a RetryWhen strategy in order to retry the request a couple of times before failing. This is needed, else the test may remain flaky when running on the CI.

[pderop]

I think that the errors from the windows checks are not related.

[pderop]

just applied the suggested changes.

[pderop]

@violetagg , thanks for your review.