fix(net): Fix TCP Unresponsiveness and Inability to Close Connections

[Samuka007]

Fix several issues that can cause TCP to get stuck on the accept state and fail to send a complete close (FIN) message.

Changes:

• Change SocketHandleItem::wait_queue to Arc, so that the listening smoltcp socket in listening posix socket could share a common wait queue and won't lose its wake on accept.
• Change the tcp socket close logic, remove the socket from socket set after poll ifce instead of before.

Todo:

• The behavior removing socket immediatly after close it may be incorrect. The close operation actually just close the transmit half of the full-duplex connection, but still could recv from remote.
• In the listening posix tcp socket TcpSocket , the handles list might have a problem. The socket behind each handle could time out and close before the accept function is called. This could cause a potential unresponsive issue.

[dragonosbot]

@Samuka007: no appropriate reviewer found, use r? to override

[Samuka007]

#743 对于不阻塞read的访问（如来自curl-8.7.1与Firefox-125.0.2的，一次访问仅建立一个连接的访问）已经能正常高效完成多次连接。对于Edge等chrome内核浏览器的访问，多个TCP连接会一直处于Establish状态，而测试程序http_server未做read阻塞超时处理（且单线程），会导致除了拥有该连接的应用，都无法再与server建立连接，属正常现象。

[fslongjin]

感觉PORT_MANAGER的入参有问题，因为它存储的是Arc<dyn Socket>，而arc是在bind的时候new的。这个应该是有问题的。我感觉是bind的时候去把socket跟端口绑定才对，这里不应该更新绑定。

[Samuka007]

应该是绑定PID号而不是绑定某个socket的引用？

[fslongjin]

@dragonosbot author 我改了一下，目前仍需修改PORT_MANAGER相关的地方。