gh-109532: fix socket HOWTO inaccuracy about send() on broken connection

Correct the claim that send() returns 0 bytes on a broken connection.
In practice, send() on a broken connection raises OSError (EPIPE) rather
than returning 0. Only recv() returns 0 bytes to indicate disconnection.

Add a clarifying comment to the mysend example noting this distinction.

Author: Gh-Novel

Doc/howto/sockets.rst

@@ -167,9 +167,10 @@ request, then reads a reply.  That's it. The socket is discarded. This means tha
 a client can detect the end of the reply by receiving 0 bytes.
 
 But if you plan to reuse your socket for further transfers, you need to realize
-that *there is no* :abbr:`EOT (End of Transfer)` *on a socket.* I repeat: if a socket
-``send`` or ``recv`` returns after handling 0 bytes, the connection has been
-broken.  If the connection has *not* been broken, you may wait on a ``recv``
+that *there is no* :abbr:`EOT (End of Transfer)` *on a socket.* I repeat: if a
+``recv`` returns 0 bytes, the connection has been broken.  A ``send`` on a
+broken connection will raise an :exc:`OSError` instead.  If the connection has
+*not* been broken, you may wait on a ``recv``
 forever, because the socket will *not* tell you that there's nothing more to
 read (for now).  Now if you think about that a bit, you'll come to realize a
 fundamental truth of sockets: *messages must either be fixed length* (yuck), *or
@@ -201,6 +202,8 @@ length message::
                sent = self.sock.send(msg[totalsent:])
                if sent == 0:
                    raise RuntimeError("socket connection broken")
+               # Note: in practice, send() on a broken connection
+               # raises OSError rather than returning 0.
                totalsent = totalsent + sent
 
        def myreceive(self):