buffer: zero-length buffers shouldn't be slab-backed
stream: Do not call endReadable on a non-empty stream

Say that a stream's current read queue has 101 bytes in it, and the
underlying resource has ended (ie, reached EOF).

If you do something like this:

    stream.read(100); // leave a byte behind
    stream.read(0); // read(0) for some reason

then the read(0) will get 0 from the howMuchToRead function.  Since the
stream was ended, this was incorrectly treating the 0 as a "there is no
more in the buffer", and emitting 'end' before that last byte was read.

Why have the read(0) in the first place?  We do this in some cases to
trigger the last few bytes of a net socket (such as a child process's
stdio pipes).  This was causing issues when piping a `git archive` job
to a file: the resulting tarball was incomplete, because it occasionally
was not getting the last chunk.
streams2: Do not allow hwm < lwm

There was previously an assert() in there, but this part of the code is
so high-volume that the added cost made a measurable dent in http_simple.

Just checking inline is fine, though, and prevents a lot of potential
hazards.
tls: follow RFC6125 more stricly

* Allow wildcards only in left-most part of hostname identifier.
* Do not match CN if altnames are present
child_process: do not keep list of sent sockets

Keeping list of all sockets that were sent to child process causes memory
leak and thus unacceptable (see #4587). However `server.close()` should
still work properly.

This commit introduces two options:

* child.send(socket, { track: true }) - will send socket and track its status.
  You should use it when you want `server.connections` to be a reliable
  number, and receive `close` event on sent sockets.
* child.send(socket) - will send socket without tracking it status. This
  performs much better, because of smaller number of RTT between master and
  child.

With both of these options `server.close()` will wait for all sent
sockets to get closed.