基于OpenAPI文档生成Mock服务器用以支持SDK开发

[Guo-Zhang]

这篇Issue接着上次关于Mock方案的讨论：https://github.com/polarismesh/polaris/discussions/561#discussioncomment-3396882。

刚非常开心地得知OpenAPI文档已经开始被添加到主项目中，这样上述Mock方案里最理想的路径是使用OpenAPI文档直接生成Mock。
下面根据此新情况阐述我的思路。

I. 量潮的已有实践

我们使用Coding DevOps托管我们的开发资源。Coding对OpenAPI有完善的支持，把OpenAPI项目作为代码仓库管理，通过持续集成功能部署到Coding提供的API文档托管，即可直接生成在线访问的API文档，并且可以一键开启Mock服务器。

关于此特性的详细描述，详见官方文档：

• 自动化流水线：https://help.coding.net/docs/document/api/automation.html
• Mock服务器：https://help.coding.net/docs/document/api/mock/usage.html

这是一套非常稳定好用的方案。我们采取官方建议的API Design First实践：

1. 设计并发布API文档，同时生成Mock服务。
2. 使用Mock服务作为开发环境开发客户端，同时作为集成测试标准验证服务端。
3. 客户端和服务端上线到测试环境(预生产环境)联调。
4. 发布API文档、客户端、服务端。

II. 北极星Mock方案

考虑到目前是直接在主项目做OpenAPI文档生成，即Code First实践。因此流程为：

1. 主项目更新API文档，生成Mock服务。
2. SDK项目使用Mock开发和单元测试。
3. SDK项目和主项目联调。
4. 发布SDK。

这里只需要找一个开源的Mock服务生成工具即可，社区的OpenAPI工具很多。

III. 组织

1. 搭建Mock服务

是一次性的工作，只需要有个可以搞定的相关同学负责即可。

2. 验证API文档

目前已经看到一些issue在做，这部分需要较多的人和时间。

3. 开发SDK验证

如果从我们Python SDK开始，我先在MVP版本跑一两个API试试看流程是否可靠。只需要有可用Mock服务即可。

[onecer]

现阶段可以基于swagger 2.0的文档生成 SDK了。

1. 访问服务端 examp.com:8080/apidocs.json 获取json格式的API文件。
2. 用该文件生成sdk，如openapi-generator generate -i apidocs.json -g go --package-name polaris -o ./internal/polaris-client