pool: TaskPool 实现 #50

[longyue0521]

TaskPool管理有限状态机，TaskExecutor负责启动任务，优雅关闭，强制退出等操作

Signed-off-by: longyue0521 longyueli0521@gmail.com

[flycash]

我觉得我大概看明白了。我有一些关于使用场景上的疑问：
按照 chanByTask 的逻辑，很显然如果用户得知道自己是不是需要使用 SlowTask。那么问题就在于，如果用户知道哪个是 slow task，它完全可以自己创建一个单独的 pool，然后不是 slow task，他就自己开 goroutine 来解决了。所以这么引入 slow queue 和 fast queue 是为了解决什么问题？

即便真需要解决场景，我觉得这样子更好：

• 你有一个 pool 的实现，就是来一个我就处理一个，也就是 fast 的，直接开 goroutine
• 你还有一个 pool 的实现，就是 slow 的，然后按照固定 goroutine 数量来调度
• 你最终有一个 pool 的实现，就是把两者结合在一起
  我觉得这种设计要比 slow 和 fast 都塞进去一个要好一点。因为我们有非常清晰的三种 pool。

另外关于 panic 的处理，我们可以内部定义个 task 的结构体：

type wrapTask struct {
    t Task
}

func (wrapTask) Run(ctx context.Context) error {
    defer func() {
            // 处理 panic 
    }
    // 后续如果我们暴露了处理 error 的回调，那么可以在这里扩展
}

即 panic 之类的这种问题，我们自己用装饰器来处理掉，那么在 pool 里面就剩下纯粹的调度逻辑了。

[codecov]

Codecov Report

Merging #57 (2f91e07) into dev (5b38f6f) will increase coverage by 4.87%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##              dev      #57      +/-   ##
==========================================
+ Coverage   89.29%   94.17%   +4.87%     
==========================================
  Files          12       12              
  Lines         514      669     +155     
==========================================
+ Hits          459      630     +171     
+ Misses         47       31      -16     
  Partials        8        8              

Impacted Files	Coverage Δ
pool/task_pool.go	100.00% <100.00%> (+100.00%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[flycash]

测试比较依赖于 sleep，这个我们后面再来优化它。我稍微有点担心后面在跑 CI 的时候，sleep 一毫秒的情况，可能因为一些乱七八糟的原因，引起了偶发性的失败

[flycash]

我要想想怎么设计一个模糊测试来测试我们这种结构，确保在长期运行的时候不会出现什么乱七八糟的情况