feat: add singleflight

[Penty-d]

自查 PR 结构

• PR 标题符合这个格式: <type>(optional scope): <description>

• 此 PR 标题的描述以用户为导向，足够清晰，其他人可以理解。

• 我已经对所有 commit 提供了签名（GPG 密钥签名、SSH 密钥签名）

• 这个 PR 属于强制变更/破坏性更改

如果是，请在 PR 标题中添加 BREAKING CHANGE 前缀，并在 PR 描述中详细说明。

这个 PR 的类型是什么？

feat: 为多个接口接入singleflight

这个 PR 做了什么 / 我们为什么需要这个 PR？

• 对singleflight进行泛型封装
• 为多个接口接入singleflight
• 修正了项目中的部分有误的error message 和 logger message
• 为部分接口补充错误分支的提前返回，避免在请求失败后继续使用空结果

(可选)这个 PR 解决了哪个/些 issue？

对 Reviewer 预留的一些提醒

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

@@            Coverage Diff             @@
##             main     #480      +/-   ##
==========================================
+ Coverage   63.81%   63.96%   +0.14%     
==========================================
  Files         230      232       +2     
  Lines        6027     6052      +25     
==========================================
+ Hits         3846     3871      +25     
  Misses       2057     2057              
  Partials      124      124              

Flag	Coverage Δ
unittest	63.96% <100.00%> (+0.14%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
pkg/singleflight/key.go	100.00% <100.00%> (ø)
pkg/singleflight/singleflight.go	100.00% <100.00%> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ozline]

1. 我看了一下你的实现，这个我们有必要在每个 Handler 的 Impl 结构体下都添加 singleflight 吗？每个 binary 运行的时候只需要共享同一个 singleflight 包（就是你加的那个）似乎就可以了，不需要每个 struct 都单独留一个，这看起来很奇怪，好像可以直接引用这个包？

2. 这个需求期望在我的理解来看应该是比较低侵入和整合的，换句话说就是：后续的同学在写入的时候可以「不知觉」的使用到这个和 singleflight，更像是一个「基建的」工作，当然确实不是所有接口都使用 singleflight，那我们也可以做一个降级：使用成本极低

3. 现在的使用成本还是有的，这个 handler 当然可以让一些命令行工具、LLM 来「吐」出来，但如果真 fallback 到人身上，起码要做两件事：在 Impl 里加上这玩意，然后查找每一个需要 singleflight 的地方（这个确实没法省），再写一个说实话我感觉使用成本挺高的 Do 函数和 Key 函数。从我粗略看的代码来看，这是可以优化整合的，你可以看看有没有可以「提取公约数」的地方

4. 如果是第一次给这个项目提 PR，并且没有实习经历的话，写的还行了，完成了最基础但很多人很难做到的「实现」这一步

[Penty-d]

1. 我看了一下你的实现，这个我们有必要在每个 Handler 的 Impl 结构体下都添加 singleflight 吗？每个 binary 运行的时候只需要共享同一个 singleflight 包（就是你加的那个）似乎就可以了，不需要每个 struct 都单独留一个，这看起来很奇怪，好像可以直接引用这个包？
2. 这个需求期望在我的理解来看应该是比较低侵入和整合的，换句话说就是：后续的同学在写入的时候可以「不知觉」的使用到这个和 singleflight，更像是一个「基建的」工作，当然确实不是所有接口都使用 singleflight，那我们也可以做一个降级：使用成本极低
3. 现在的使用成本还是有的，这个 handler 当然可以让一些命令行工具、LLM 来「吐」出来，但如果真 fallback 到人身上，起码要做两件事：在 Impl 里加上这玩意，然后查找每一个需要 singleflight 的地方（这个确实没法省），再写一个说实话我感觉使用成本挺高的 Do 函数和 Key 函数。从我粗略看的代码来看，这是可以优化整合的，你可以看看有没有可以「提取公约数」的地方
4. 如果是第一次给这个项目提 PR，并且没有实习经历的话，写的还行了，完成了最基础但很多人很难做到的「实现」这一步

感谢小黄老师指点，我能get到你说的点，其实我一开始也觉得有点过于繁琐了，但第一时间思路有点歪了，一直想着sf做成实例子然后do方法调用，后续几个commit思路也没纠正过来（
后续会只在sf包内维护一个group，这样不用在impl里加sfgroup，do做成泛型函数，降低使用成本，key的使用我目前没有想到更好的方案orz