fix stream unable to disconnect when it is full

[guyco3]

Fixes #4828

Problem

ZMQ_STREAM server cannot disconnect a client if the SNDHWM has been reached. This happens because the stream_t::xsend logic returns EAGAIN on the first frame (the Routing ID) when check_write() fails, preventing the socket from ever receiving the second frame (the 0-byte disconnect signal).

Solution

defer the check_write() call from the Routing ID frame to the actual payload frame. This allows the socket to identify the peer and process a termination signal even under HWM pressure. Actual data payloads still correctly trigger EAGAIN if the pipe is full, preserving existing backpressure behavior.

• If the subsequent payload frame is 0 bytes (a disconnect signal), it is processed immediately via terminate(), bypassing the HWM.
• If the subsequent payload frame contains data (size > 0), the HWM check is enforced at that stage to maintain standard flow control.

Verification

• Added a new test case: tests/test_stream_hwm_disconnect.cpp.
• Before fix: Disconnect failed with EAGAIN.
• After fix: Disconnect succeeds even when the sending queue is full.

[pijyoi]

In the test, after the sndhwm is reached, you have a comment that at that point, it is unknown whether the socket is in the "more" state. The subsequent code then deals with both cases.

It seems to me that there is a race? Let's assume that the socket is in the "more" state. Before you send the routing_id frame, is it possible for the sndhwm to transition to no longer full? If yes, then that would result in the routing id frame being sent as a payload to the client.

Perhaps the "more" state should be reset if the sndhwm is reached?

I see that #4829 added an API zmq_disconnect_peer but only implemented for SERVER sockets. If support for STREAM sockets was added, that would also solve the issue. i.e. sending empty frame to disconnect would be deprecated in favor of using zmq_disconnect_peer.

[guyco3]

Thanks for the feedback, I looked into the zmq_disconnect_peer approach as you suggested. While that API is a great addition, I think fixing the xsend logic is the right path for ZMQ_STREAM for the following reason (open to discussion though):

API Incompatibility: zmq_disconnect_peer currently takes a uint32_t routing ID. ZMQ_STREAM identities are 5-byte frames (0x00 + 4-byte ID). Forcing STREAM users to use this API would require them to manually parse the identity frame to extract the last 4 bytes in network order (e.g., ntohl(*(uint32_t*)(data+1))). Additionally, STREAM supports custom identities that will probably not map cleanly to uint32_t since they might be longer.

Current Progress:
I am still working fixing the race you mentioned and writing a good test file into the libzmq test suite to verify this behavior. I will update the PR once the test file is finalized and verified.