Crash with port scanner

When running chisel as a reverse socks proxy with a port scanner, the server crashes with the following messages:

accept4: too many open files
and
Stream error: ssh: unexpected packet in response to channel open: <nil>
The server runs with:
chisel server -p PORT --reverse --socks5
The client:
chisel client IP:PORT R:socks

and the port scanner is naabu (https://github.com/projectdiscovery/naabu) running with:

naabu -s connect -p - --exclude-ports 22 -host IP -proxy 127.0.0.1:1080

The chisel's server version is 1.7.4-0kali1, the client's one is 1.7.7_linux_386.

Here is a more complete stack trace:

`➜ ~ chisel server -p 443 --reverse --socks5
2022/08/03 20:17:59 server: Reverse tunnelling enabled
2022/08/03 20:17:59 server: Fingerprint 6wKlRlcflpJKXqpdABDOc8GANiXRlavVxtbNbcWYQqM=
2022/08/03 20:17:59 server: Listening on http://0.0.0.0:443
2022/08/03 20:18:01 server: session#1: Client version (1.7.7) differs from server version (0.0.0-src)
2022/08/03 20:18:01 server: session#1: tun: proxy#R:127.0.0.1:1080=>socks: Listening

2022/08/03 20:20:10 server: session#1: tun: proxy#R:127.0.0.1:1080=>socks: Accept error: accept tcp 127.0.0.1:1080: accept4: too many open files
2022/08/03 20:20:10 server: session#1: tun: proxy#R:127.0.0.1:1080=>socks: conn#80847: Stream error: ssh: unexpected packet in response to channel open:
2022/08/03 20:20:10 server: session#1: tun: proxy#R:127.0.0.1:1080=>socks: conn#80852: Stream error: ssh: unexpected packet in response to channel open:
2022/08/03 20:20:10 server: session#1: tun: proxy#R:127.0.0.1:1080=>socks: conn#80846: Stream error: ssh: unexpected packet in response to channel open:
...`

Interestingly enough, the same kind of scan doesn't crash when using nmap (I am guessing there is less threads).

Reproduce the failure with the reported chisel server and client commands, then run the naabu connect scan through the reverse SOCKS proxy. Start from the SOCKS listener and channel-open error path shown in the stack trace. Done means the scan no longer crashes the server and the resulting connection errors are handled without exhausting the available file descriptors.