Fix two more bugs.

Unfortunately, two more subtle bugs to fix:

- If the encoded protobuf message is only three bytes long (or less),
  not only the whole protobuf will fit into headerBuf, but also the
  beginning of the next length varint. This will completely wreak
  havoc in the read process. (This bug never bit us in Prometheus
  because the protobuf messages were all long enough. But protobufs in
  general can be very small (0 bytes in fact). I added a test for
  that.)

- If the reader stops in the middle of a length varint, it will
  interpret the null byte that is already in headerBuf as the final
  byte of the varint, which again wreaks havoc. (This bug only shows
  up in Prometheus after
  https://github.com/prometheus/prometheus/commit/dfb9c2a072d5c1003e78c4921988c21bc76ab07a
  , and it is very rare... needs very unlucky fragmentation on the
  network.)

Solution to the first bug is to read byte-wise, which is slightly less
effective, but simplifies the code later, because we don't "overshoot"
anymore. Solution to the second bug is to only read the parts of
headerBuf that have been written to.
I'm not saying we need to accommodate bad implementations of ``io.Reader``; what I am saying is that it took me quite a while to reason with the flow of things, because the present flow combined with the contract expectations are non-obvious:

1. It was not clear to me until I read the source for ``proto.DecodeVarint`` and traced its output is that it can incrementally consume incomplete varint byte streams until it gets a terminated sequence.  (Its docstring doesn't mention this, either.)  This is worth commenting in the decoding pipeline.  This caused considerable confusion.

2. It had appeared from this undocumented behavior in item 1, that we could underestimate the size of an encoded message with this change because of only advancing one byte at a time in the decoding process: ``headerBuf[bytesRead : bytesRead+1]`` This was troubling.  In our tests (as they are written now and in your change), we never pass a message into the decode that requires more than one byte to represent with the varint encoding.  Thusly, if there was an error (as it appeared under the view of the first item), we would always succeed.

The long and the short of it: Nobody should have to consult the code review history to understand this minutia for something that should be as simple as this.

As for the empty message case, I completely agree.

Why merging #6 beforehand is important to me, is that I have a sneaking suspicion that the incremental reading approach you take in this P.R. introduced other problems, problems that the enhanced fuzz test and manual test case I have here will catch.  I just want to be sure that further changes add no regressions.