Optimize HTTP messages with empty payload body

[idelpivnitskiy]

Motivation:

In many cases users do not set payload body when they create an HTTP
request (like GET) or response (like, 204). We can optimize flush
strategy and HTTP/1.1 encoding in these cases.

Modifications:

• Introduce PayloadInfo#isEmpty() flag that tells internal layers when
  an HTTP message contains payload body;
• Use this flag to choose a flush strategy and set content-length header;
• Adjust existing content-length tests to verify new use-cases with
  empty payload body;
• Enhance existing FlushStrategyOnServerTest to verify empty responses
  flush on end;
• Filter out empty payload body buffer when converting between types;
• Add more tests to verify users can keep using different ways to set payload;

Behavior changes:

• Users cannot write more data into a payload body Buffer of new
  request/response objects after types conversion:

HttpRequest request = streamingHttpClient().asClient().post(SVC_ECHO);
StreamingHttpRequest streamingRequest = request.toStreamingRequest();
// Too late to take the buffer from the original aggregated request object, modifications won't be visible:
Buffer payload = request.payloadBody();
payload.writeAscii(CONTENT);
assertResponse(makeRequest(streamingRequest), request.version(), OK, 0);

• Streaming HTTP/1.1 requests and responses with empty payload body are
  encoded with content-length: 0 instead of transfer-encoding: chunked;

Result:

Less flushes + non-chunked HTTP/1.1 encoding when there is no payload body
results in better throughput (+30% RPS) for these use-cases, latency improves
by ~15%.

[bondolo]

Seems like a quite worthwhile improvement!

[bondolo]

What would be result for an explicitly empty payload such as empty String or empty byte array?

I am thinking of the case were app has their own empty payload response and they use it as the payload for a response they intend to be empty.

[idelpivnitskiy]

Unfortunately, in order to support this use-case, we can not apply the optimization in the scenarios you highlighted, because users can expand it later. If in future we will agree to drop support for this way, we will be able to optimize any empty payload body.

However, if users set a read-only empty buffer, we can support it. Fixed: 69e962f