fix off-by-one in ProtocolGet and ProtocolOpenDir recv buffers

[aizu-m]

Tracing the file-receive path in libcfnet/protocol.c.

TLSRecv() NUL-terminates what it reads:

tls_generic.c:  buffer[received] = '\0';   // received can equal toget

So the buffer must hold toget + 1 bytes. net.c does exactly that already
with char proto[CF_INBAND_OFFSET + 1] for a CF_INBAND_OFFSET read.

ProtocolGet() and ProtocolOpenDir() declare buf[CF_MSGSIZE] yet receive
up to CF_MSGSIZE bytes. GET goes straight through TLSRecv(ssl, buf, CF_MSGSIZE). OPENDIR goes through ReceiveTransaction(), whose length cap is
CF_BUFSIZE - CF_INBAND_OFFSET, i.e. CF_MSGSIZE. A peer that fills the
record makes received reach CF_MSGSIZE, so the terminating NUL is written
to buf[CF_MSGSIZE], one byte past the array. The byte count is server
controlled, so the reach crosses the trust boundary.

Confirmed by modelling the terminating write with a guard byte placed right
after the buffer: the guard is clobbered at CF_MSGSIZE, intact once the
buffer is CF_BUFSIZE.

ProtocolStat() in the same file already sizes its buffer CF_BUFSIZE. The
other two now match it.

[cf-bottom]

Thank you for submitting a pull request! Maybe @craigcomstock can review this?

[nickanderson]

Thanks for the contribution. I have a PR with a test that exposes it and shows the test passes with your commit over in #6177

Closing this one in favor of that one