fix: poll POLLOUT in a loop instead of aborting after single 300ms miss

[mangodxd]

WHY

ZMQ's async event loop polls POLLOUT once per send attempt. When the socket buffer is full (common under heavy load), a single 300ms POLLOUT miss causes SaltClientError, crashing the minion connection.

HOW

• Poll POLLOUT in a loop with a 300ms timeout each iteration, rather than aborting after the first miss.
• Loop continues until either POLLOUT fires or total timeout exceeds the caller's deadline, matching ZMQ's internal behavior for high-water-mark backpressure.
• The fix lives in salt/transport/zeromq.py's send() method which is the only caller affected by this edge case.

VERIFY

• Added ests/unit/transport/test_zeromq.py with a mocked POLLOUT-miss scenario that repeatedly returns no POLLOUT events, then returns POLLOUT on the Nth attempt.
• Before the fix, est_pollout_miss_retry_success and est_pollout_all_misses_timeout fail; after the fix, both pass.
• Existing ZMQ transport tests unchanged and passing.
• Changelog entry added at changelog/69816.fixed.md.

Fixes #69816

[twangboy]

If socket.poll(300, zmq.POLLOUT) blocks for up to 300ms, the request future could potentially time out or be cancelled right during that poll window.

To prevent sending a message after the request has already been marked done/cancelled, we should double-check future.done() right after poll() returns True before executing socket.send().

            if await socket.poll(300, zmq.POLLOUT):
                if future.done():
                    break
                await socket.send(message)
                sent = True
                break

[mangodxd]

Fixed in 5ad9022. Also checked 3006.x — it uses a different architecture (tornado generators, not asyncio RequestClient._send_recv) so the same POLLOUT issue does not exist there.

[twangboy]

Also, if this issue exists on 3006.x branch, the fix should be done there.