[OPTIM] http: optimize chunking again in non-interactive mode

Now that we support the http-no-delay mode, we can optimize HTTP
chunking again by always waiting for more data to come until the
last chunk is met.

This patch may or may not be backported to 1.4, it's not a big deal,
it will mainly help for chunks which are aligned with the buffer size.
diff --git a/src/proto_http.c b/src/proto_http.c
index 391d630..1fc7c94 100644
--- a/src/proto_http.c
+++ b/src/proto_http.c
@@ -4564,15 +4564,11 @@
 		buffer_dont_close(req);
 
 	/* We know that more data are expected, but we couldn't send more that
-	 * what we did. In theory we could always set the BF_EXPECT_MORE so that
-	 * the system knows it must not set a PUSH on this first part. However
-	 * there exists some applications which incorrectly rely on chunks being
-	 * interactively exchanged. So we set the flag only if the current chunk
-	 * is not finished, or we're not DONE and interactive mode is not set.
+	 * what we did. So we always set the BF_EXPECT_MORE flag so that the
+	 * system knows it must not set a PUSH on this first part. Interactive
+	 * modes are already handled by the stream sock layer.
 	 */
-	if (txn->req.msg_state >= HTTP_MSG_DATA &&
-	    txn->req.msg_state <= HTTP_MSG_TRAILERS)
-		req->flags |= BF_EXPECT_MORE;
+	req->flags |= BF_EXPECT_MORE;
 
 	http_silent_debug(__LINE__, s);
 	return 0;
@@ -5605,15 +5601,11 @@
 		buffer_dont_close(res);
 
 	/* We know that more data are expected, but we couldn't send more that
-	 * what we did. In theory we could always set the BF_EXPECT_MORE so that
-	 * the system knows it must not set a PUSH on this first part. However
-	 * there exists some applications which incorrectly rely on chunks being
-	 * interactively exchanged. So we set the flag only if the current chunk
-	 * is not finished, or we're not DONE and interactive mode is not set.
+	 * what we did. So we always set the BF_EXPECT_MORE flag so that the
+	 * system knows it must not set a PUSH on this first part. Interactive
+	 * modes are already handled by the stream sock layer.
 	 */
-	if (txn->rsp.msg_state >= HTTP_MSG_DATA &&
-	    txn->rsp.msg_state <= HTTP_MSG_TRAILERS)
-		res->flags |= BF_EXPECT_MORE;
+	res->flags |= BF_EXPECT_MORE;
 
 	/* the session handler will take care of timeouts and errors */
 	http_silent_debug(__LINE__, s);