feat: manage grpc apis with csv and automatic proto genenration

[cxw620]

Generated with mikufans-bapis-decompile-helper@0.1.5 from official apk iBiliPlayer-apinkRelease-8.6.0-b15481705

[cxw620]

All works done and protos are checked with protoc. This PR is ready to be merged. Any comments? cc @z0z0r4 @SocialSisterYi

Old proto files (some with comments) have been move to dir deprecated, since mikufans-bapis-decompile-helper does not support managing services / classes / fields comments now. Another PR will be raised when I implement it, though may cost mush time for I'm busy these days.

[z0z0r4]

我对 grpc 完全不了解…

[SocialSisterYi]

All works done and protos are checked with protoc. This PR is ready to be merged. Any comments? cc @z0z0r4 @SocialSisterYi

Old proto files (some with comments) have been move to dir deprecated, since mikufans-bapis-decompile-helper does not support managing services / classes / fields comments now. Another PR will be raised when I implement it, though may cost mush time for I'm busy these days.

如果直接对原有 gRPC 的 proto 移至 deprecated中，合并后会割裂现有的社区贡献进程，以及迁移注释的工作量庞大且繁琐。最近我也忙于工作，管理项目时间不足。但对于 gRPC 的管理，我有几点建议：

1. 使用 .csv / .xlsx 表格对 proto 结构体的 services / message / oneof / enum / fields 进行结构化管理（类似关系型数据库），以 tag 和 id 作为索引，附加注释、类名等管理困难的信息
2. 使用 Action 生成完整的 proto 结构树（目录和文件级别），并更新至仓库
3. 后续 gRPC 的管理不直接改动 proto 文件，只改动各 .csv / .xlsx 文件方便自动化分析新增字段

[cxw620]

All works done and protos are checked with protoc. This PR is ready to be merged. Any comments? cc @z0z0r4 @SocialSisterYi
Old proto files (some with comments) have been move to dir deprecated, since mikufans-bapis-decompile-helper does not support managing services / classes / fields comments now. Another PR will be raised when I implement it, though may cost mush time for I'm busy these days.

如果直接对原有 gRPC 的 proto 移至 deprecated中，合并后会割裂现有的社区贡献进程，以及迁移注释的工作量庞大且繁琐。最近我也忙于工作，管理项目时间不足。但对于 gRPC 的管理，我有几点建议：

1. 使用 .csv / .xlsx 表格对 proto 结构体的 services / message / oneof / enum / fields 进行结构化管理（类似关系型数据库），以 tag 和 id 作为索引，附加注释、类名等管理困难的信息
2. 使用 Action 生成完整的 proto 结构树（目录和文件级别），并更新至仓库
3. 后续 gRPC 的管理不直接改动 proto 文件，只改动各 .csv / .xlsx 文件方便自动化分析新增字段

了解, 那我先保留但是搁置这个 PR.

但是有个问题, Github Action 不会有资源限制么(看了眼, 4H16G, emmm), jadx decompile 很吃 CPU 和内存, 8845HS, -Xmx16G -j 16 也得 2 分半, 实际工具解析 jadx jsons 倒是非常快, release profile build 1秒左右就解析完了()

xlsx 的话 rust 没比较好的库, 也不便于 git diff, 应该还是采用 csv ()

那么总的来说, 我能否理解为只需要按照一定的格式将解析得到的中间数据以 csv 的格式输出并 commit, 社区只需要维护这个 csv, 最后定期用 Github Action 运行我的 helper tool 读取 csv 以 proto 格式输出并打包发布 proto files. 这样的话倒是蛮好改的. 工作量还是在迁移注释上. 总不能还得写个 GUI 吧