feat: support RPC protocol write

[castlighting]

No description provided.

[shoothzj]

why we need this dependency?

[shoothzj]

I guess vertx-grpc is better?

[castlighting]

EN:

After I read the entire JavaSDK project, I personally feel that the overall style of the SDK leans towards an asynchronous approach. This is one of the main reasons why I chose to encapsulate grpc-vertx in grpc-java. One thing that needs to be clarified is that I am not a believer in vertx. I just feel that using grpc-vertx is more in line with the current style of the project.

In theory, it is true that using grpc-vertx may have better performance than grpc-java. At least compared to grpc-java's traditional blocking calls, it can better handle a large number of concurrent connections, making it perform better in high concurrency scenarios. At the same time, Vert.x's event loop model can handle more requests with fewer threads. Of course, whether it will significantly improve our project still needs to be proven by Beenchmark, which is also in my follow-up plan.

Even if I ultimately do not use grpc-vertx and instead use grpc-java directly, it will not have a destructive impact on the module I developed. This is thanks to the encapsulation of the ConnectionManager, Stub, and implementation methods in the module, making it very easy to replace without affecting other core logic (decoupling).

ZH-CN:

在我阅读完整个JavaSDK项目后，个人认为SDK的整体风格偏向于异步的方式，这是我选择在grpc-java上封装的grpc-vertx的最大原因之一，需要澄清一点的是我并不是vertx信徒，我只是觉得使用grpc-vertx要更加符合当前项目的风格。

理论上来说确实使用grpc-vertx可能要比grpc-java性能要更好，至少相比 grpc-java 的传统阻塞式调用,能够更好地处理大量并发连接使得它能够在高并发场景下性能更优同时Vert.x 的事件循环模型可以用更少的线程处理更多请求，当然是否对我们的这个项目具有显著的提升还是需要Beenchmark来证明，这也在我后续的计划中。

就算最终不使用grpc-vertx采取直接使用grpc-java的方式并不会对我所开发的模块造成破坏性的影响，这要得益于我在模块中对ConnectionManager、Stub以及执行方式的封装，使得替换起来非常轻松不会影响到其它的核心逻辑（解耦）。

[shoothzj]

avoid use star import