While proto_common_recv() was intended to not return until it has
received the entire requested amount of data or an error occurs, in
practice, due to a bug in the AF_UNIX socket code, it was returning
short reads, and the protocol code was relying on this. When the socket
bug was fixed, this resulted in hastd blocking where it previously would
have returned a short read, so proto_connection_recv() would block
forever trying to read 127 bytes where the other side was only sending
four (typically "tcp\0" or "uds\0").
Replacing MSG_WAITALL with 0 reestablishes the status quo, but that
still leaves us in a situation where callers of proto_recv() may
unknowingly receive less data than they expected. We fix this by having
proto_recv(), tcp_recv(), uds_recv(), and proto_common_recv() return an
ssize_t instead of just 0 or an error code, and having the callers
check that the returned length matches their expectations.
For symmetry, we do the same for the *_send() functions, even though
they already handle short writes by looping.
We also tighten the check in proto_connection_recv() so we accept e.g.
"tcp\0" as intended but not "tcp\0is my jam\n".
While here, replace bcopy() and bzero() with memcpy() and memset().
Reported by: Martin Vidovic <xtronom@gmail.com>
MFC after: 3 days