http: correcting Content-Length header behavior on HEAD

Currently there's a slight perverse interaction between code intended
to prevent sending a null-chunk on 204/304 response codes and socket
re-use. HEAD requests can re-use a socket, apparently if and only if
they have either content-length or content-encoding headers, or the
response status is 204. The objective of this slight change is to
allow non-204 responses without bodies (e.g. in response to HEAD) to
set the payload headers that would have been sent normally. Both the
old and new behaviors are compliant with RFC7231 (see 4.3.2) and
RFC2616 (see 14.13).

Refs: https://tools.ietf.org/html/rfc7231#section-3.3
Refs: https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
Fixes: #28438

lib/_http_outgoing.js

@@ -431,7 +431,8 @@ function _storeHeader(firstLine, headers) {
   }
 
   if (!state.contLen && !state.te) {
-    if (!this._hasBody) {
+    if (!this._hasBody && (this.statusCode === 204 ||
+                           this.statusCode === 304)) {
       // Make sure we don't end the 0\r\n\r\n at the end of the message.
       this.chunkedEncoding = false;
     } else if (!this.useChunkedEncodingByDefault) {