net: recvfrom says who sent it, and a datagram is delivered whole

The second of the two things the stack owed. recvfrom accepted the
address arguments and ignored them, so every caller was told nothing
about where a datagram came from -- which for UDP is most of the point:
a server that cannot see the sender cannot reply to it.

Fixing it properly meant fixing something worse that was sitting
underneath. UDP payloads went into the same byte ring TCP uses, with no
record of where one datagram ended and the next began, so two datagrams
that arrived together came back from one read as one. That is a bug
whose appearance depends on timing and whose blame lands on the sender.

Datagrams now carry a header alongside the bytes: source address, source
port, length. Sixteen of them per socket, in a ring beside the existing
one. Whole buffers would have been 16 sockets x 16 datagrams x an MTU of
static memory for something almost always empty; only the boundaries need
keeping, and those are eight bytes each. A datagram too big for the
buffer it is read into is truncated and the remainder discarded, rather
than left in the ring to be delivered as the head of the next one. One
that arrives with the queue full is dropped whole -- that is UDP's own
contract, and half a datagram in the ring would corrupt every one after.

An empty queue and a zero-length datagram are kept apart, because a
sender really can send zero bytes and the right answer to that is 0
rather than "nothing has arrived yet".

sendto grew the mirror image: a destination address on a datagram
socket, which is what a server replying to whoever just wrote to it
needs. On TCP a destination is ignored rather than refused -- the
connection decides where the bytes go, and programs pass one out of
habit. For a stream, recvfrom's source is read from the pcb: it is the
peer, and it is the same answer for every byte.

Verified: bootcheck -Net now covers UDP too, 45 [ok] and no failures.
The address check is real rather than cosmetic -- nettest deliberately
leaves its sockaddr uninitialised, so a kernel that filled in nothing
would print stack rubbish instead of 10.0.2.2 and the port the responder
is actually on. The boundaries are checked by byte count: the responder
sends 20 bytes and then 16, and the guest reports reading 20 and then
16. Treated as a stream the first read would have taken all 36.

Left for later, and deliberately: accept() still does not report the
peer's address, and getsockname/getpeername do not exist.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

kernel/net/unix.c

@@ -552,3 +552,38 @@ sock_domain(struct socket *s)
 {
   return s ? s->domain : 0;
 }
+
+// recvfrom and sendto, which differ from read and write only in carrying an
+// address. Both live here rather than in sys_net.c for the same reason as
+// sock_domain: the syscall layer must not know which side of the socket union
+// is live.
+//
+// `port` comes back in host byte order, matching what sockbind_in and
+// sockconnect_in take. The syscall layer converts on the way out, in the one
+// place that also builds the sockaddr.
+int
+sockrecvfrom(struct socket *s, char *buf, int n, uint *addr, ushort *port)
+{
+  if(n < 0)
+    return -EINVAL;
+  if(s->domain == AF_INET)
+    return inet_recvfrom(s->inet, buf, n, addr, port);
+
+  // A Unix socket has no address of this shape. Saying so by leaving the
+  // caller's address untouched, rather than inventing one, is what lets
+  // recvfrom report an address length of zero -- which is exactly what a
+  // program reading from an unnamed peer expects.
+  return sockread(s, buf, n);
+}
+
+int
+socksendto(struct socket *s, char *buf, int n, uint addr, ushort port)
+{
+  if(n < 0)
+    return -EINVAL;
+  if(s->domain == AF_INET)
+    return inet_sendto(s->inet, buf, n, addr, port);
+  if(addr)
+    return -EAFNOSUPPORT;      // an AF_INET destination on an AF_UNIX socket
+  return sockwrite(s, buf, n);
+}