initialize command_queue on check_channel_request to avoid race

[skshetry]

Paramiko runs methods from ServerInterface in its own thread. The check_channel_request is called when a new channel is requested, before the channel is actually created and returned by transport.accept(). After the request is granted by check_channel_request, the channel is created and returned by transport.accept().

See
https://docs.paramiko.org/en/stable/api/server.html#paramiko.server.ServerInterface.check_channel_request.

There is sometimes a race where check_channel_exec_request is invoked around the same time that transport.accept() returns a channel, to Handler.run().

Both race to create the command queue for the channel. When Handler.run() wins, the command added to the queue by check_channel_exec_request is lost into the void. The client receives no response and hangs indefinitely, freezing the test suite.

To fix this, we could either add a lock around both places where we create the command queue, or we could just create the command queue in check_channel_request, which always run before Transport.accept() returns.

I chose the latter, as it's simpler and avoids the need for locks.

---

This patch has been tested on fsspec/sshfs#66 (please ignore other changes, I am trying to fix another test at the same time), where I ran >200 test jobs.
We were seeing test freezing intermittently, and when I investigated, I discovered this issue.

See https://github.com/fsspec/sshfs/actions/runs/18935359445/job/54060844842#step:5:22 for instance.

[skshetry]

ubuntu-latest is now ubuntu-24.04, which does not support Python 3.7. See:

• Error: Version X with arch x64 not found actions/setup-python#162.