Kotlin：对 Signal 进行升级

[Gaubee]

Signal的设计来源于JS的EventSource，而JS的EventSource这种设计模式是面向UI做的设计。 它本身的设计出发点，就是事件可丢弃。类似BroadcastChannel

因此将这个设计给到Signal会存在很大的隐患，这点我们已经在 ipc ready 这个点上遇到过了，现在 ipc ready 就是采用轮训的方式一直来建立握手，这是一个很失败的底层设计。

Signal 还有一个挑战，就是它的 listen 是不需要 suspend 介入，只有emit需要，这就意味着一些隐患：一个事件的触发，是它的sender可以决定什么时候结束，而不是receivcer来决定什么时候结束。也就是说receivcer所提供的suspend函数的生命周期不是receivcer自己能决定的，这在很多场景里就是一种错误。

[Gaubee]

Flow 与 Signal 最大的区别在于： Flow 在发送方和接收方都有独立的 context Signal 只有在发送方有 context， 接收方与发送方共用同一个 context

所以如果要做到最小变更，我们只需要在这个context上入手：让Signal也可以配置接收方的context

[waterbang]

1. 避免需要创建一个channel去解决顺序队列缓存的情况
2. 避免onEvent 的orderBy 排序，减少代码量
3. emit 能等待全部的listen触发

[waterbang]

close of 83e0fbc0c1e01bc88a7790560d24f50adfa42022