restore unix non-blocking helper for sockevent

[yuchanns]

上一个 commit 改动破坏了 Linux 和 macOS 的构建

[yuchanns]

麻烦 soluna 也更新下依赖, 懒得为更新 3rd 再发起一个 pr 了 :)

[cloudwu]

暂时可以这么修。不过，我今天研究了一下之前的实现，我认为作为本地通讯，这个 none blocking 是没有必要的，所以我从 windows 分支中去掉了。尤其是最近的一次 windows 更新后，在握手（connect/accept) 阶段使用 none blocking 是有问题的，我今天测试有可能初始化死锁。（对此 gemini 给了一段我觉得未必可信的解释，不过我的测试结果表示的确有问题）

至于握手后设置 none blocking ，我觉得在 loopback 下也没有必要。不过这个 socketpair 是 @actboy168 加的。看看是不是有其它考量，还是只是照着之前的代码写的顺手加上的 none blocking 。

如果可以去掉 none blocking ， 我认为从简化代码角度是更好的。

[cloudwu]

去掉 none blocking 正确性肯定没有问题。如果有影响，可能发生在 send 的阻塞上，或许或有潜在的性能下降。但是，无论是 linux mac 还是 windows ，我觉得 loopback 设备上的 send ，在 ltask 的使用场合（用于独占服务间发信号），发送缓冲区都不可能满，不会涉及发送信号方的线程挂起操作。而且 ltask 的实现中，socketevent.h 里，连 send 返回值都没检查，用非阻塞模式理论上是有点问题的。

我又看了一下，后来加的 socketpair 代码。这里，实际上是不是用阻塞模式，这里的 send 都不要求真的把数据发出去。因为这里只用来发信号，不需要实际的通讯。但 https://github.com/cloudwu/ltask/blob/master/src/sockevent.h#L198 这里的 wait 需要 e->pipe[0] 阻塞，保证这个 recv 阻塞。因为这个 socketpair 用的本地的 PF_UNIX ，所以其实没有影响而已。此处不可能又缓冲区满的问题。 https://github.com/cloudwu/ltask/blob/master/src/sockevent.h#L124 这个设置理论上不对。

综上，我觉得应该完全去掉 none blocking 。稍后我会重新改一下。