libssh2_channel_close() can lead to deadlock on MacOS

[twitzelbos]

Describe the bug
I have observed that in ssh2-rs one of the unit tests has a tendency to deadlock on MacOS. What the test does is to issue a libssh2_channel_process_startup with "shell" as request, immediately followed by a libssh2_channel_close(). From what I can see is one of two things happening:
(note this is using non-blocking sockets):
A) no deadlock, but when close() waits for the remote SSH_MSG_CHANNEL_CLOSE message, it receives a SSH_MSG_CHANNEL_REQUEST with exit-signal instead, but close doesn't actually check what the received response was and moves on happily. The SSH_MSG_CHANNEL_CLOSE is received eventually as well, when the socket is wound down, but close() while waiting for it, never "saw" it.

B) deadlock: when close() waits for the remote SSH_MSG_CHANNEL_CLOSE message, it receives a EAGAIN error, and goes to socket_wait, where it will hang at poll() forever. Note that in this test, there is no configured timeout, so poll is called with timeout -1. But even if there was a timeout, things are clearly going really wrong.

adding a 100ms sleep between libssh2_channel_process_startup and libssh2_close() seems to NEVER cause a deadlock. I only observe this in a local test on Macs (server is also on the same local Mac). It also causes the MacOS github actions in ssh2-rs to hang on occasion. I cannot reproduce this on Linux or Windows.

To Reproduce
Steps to reproduce the behavior.

See above, I'll try to get better info.

Expected behavior
Not deadlock.

Version (please complete the following information):

• MacOS 11 and 12, x86 and M1
• libssh2 version: [e.g. 1.11.0]
• crypto backend and version: N/A

Additional context
I realize this is a bit of a strange observation, and I acknowledge that perhaps the test in ssh2-rs is an anti-pattern, yet a deadlock should not occur.