群聊&私聊合并转发消息发送

[Aliorpse]

文本能正常发送，其他没测

[ForliyScarlet]

Qodana Community for JVM

It seems all right 👌

No new problems were found according to the checks applied

💡 Qodana analysis was run in the pull request mode: only the changed files were checked
☁️ View the detailed Qodana report

Contact Qodana team

Contact us at qodana-support@jetbrains.com

• Or via our issue tracker: https://jb.gg/qodana-issue
• Or share your feedback: https://jb.gg/qodana-discussions

[ForteScarlet]

首先，同步分支确保提交分支与当前dev/main分支内容的历史匹配，不要在提交记录中包含大量已过期或已合并的提交历史。

其次的其他内容：

• 有关API的实现与提供，作为非标准API，或许应该考虑以 top-level 扩展函数的形式而不是直接在接口内增加函数的形式来提供Xxx.sendForwardMsg。
• 也许需要为这些API和扩展增加 opt 注解 ，例如 @NonstandardOneBotApi
• 枚举 OneBotBrend 似乎没有实际作用，并且与当前主题无关。

扩展API或许也可以考虑作为独立的模块，或者直接以第三方的形式直接发布？这部分仍待讨论

[Aliorpse]

冗余提交历史这块 因为我是直接 fork 了 master, 抱歉 ，我这边重新 fork 一遍 dev/main 然后提交拉过去 到时候重新 pr 一下

我觉得扩展API不应该作为第三方库发布，因为现在几乎没有 onebot 实现在使用标准的 onebot 接口处理转发消息，保持这点代码洁癖可能没有什么必要。可以参考 koishi， nonebot 以及其他机器人框架的实现， 他们都是直接内置在类似于 adapter-onebot 类似的包中。如果单独抽离这些API，用户在使用时也需要额外的添加一个依赖，至此几乎所有用户为了适配合并转发消息而必须加这个依赖，那分模块的意义也失去了。

为这些方法添加 @NonstandardOneBotApi 类似的注解我赞同，但是 optIn 我觉得没什么必要（）

所以有关这些所谓 非标准API 我认为还是要根据当前协议端的适配情况 以及大众的倾向来看，即使 /send_group_forward_msg 本身没有包含在 onebot 标准内，但是大家都已经心照不宣地用，这何尝不是一种标准呢

枚举 OneBotBrand 最初我是想直接通过获取对应实现直接在 SendGroupMsgApi 中动态判断实现品牌来决定需要用哪个 action，但是依据项目结构来看似乎这并不妥，所以就搁置在这了。

[ForteScarlet]

• OneBotBrand 如果没有实际意义的话就一并移除吧。至于它原本期望的动态判断之类的，也许考虑在 考虑支持方言 #123 的讨论基础上，未来为内部的API调用增加类似方言的东西。
• sendForward 的返回值类型应与 send 一致，返回 OneBotMessageReceipt 而不是 API 的直接返回类型。
• 非标准API应该有一个新的 package，比如 ...api.unstandard。同时，为 module-info.java 追加新包的导出。
• 新增的类型和函数应该标记 @since，目前来看的下一个版本应该是 1.9.0。
• 注意确保新增类型后通过 gradle apiCheck 检查和 gradle detekt 的检查与修复。如果执行 gradle apiDump 更新 .api 内容，确保变更的 *.api 文件变更只有新增内容，没有变更或移除的行（确保abi兼容）
• 确保测试所有类型都可使用，并需要明确测试的是哪个实现者。

目前阶段的建议：只提供与两个 Api 类型实现的相关内容，暂不提供 sendForward 等其他内容，它们需要做更多工作。

如果之后打算重新PR，那么当前PR你看情况自行关闭就可以。