4.x: gRPC

[tomas-langer]

Eventually we should have just one gRPC implementation based on Níma (align with current gRPC implementation so user experience is similar) ProtoMarshaller uses reflection, should be removed if possible.

• [x] #5323
• [x] #5387
• [x] #7060
• [ ] #7067
• [ ] #7005
• [ ] Annotation support (with eye towards Helidon Declarative)

Need to reconcile with issues identified in #6683

grpc for MP is temporarily removed from the repository, this issue also includes the requirement to bring back the full grpc implementation to Helidon (including client), as well as documentation for grpc.

[tomas-langer]

Related to #5323

[rbair23]

@tomas-langer, I have a need for an alternative gRPC implementation. We have written a lightweight, zero dependency*, fast protobuf library called PBJ which can be used instead of protoc and grpc.io libraries. I started a Helidon module for PBJ: https://github.com/hashgraph/pbj/issues/257.

One of the questions I am being asked is whether we can reuse chunks of the official Helidon gRPC module, rather than reimplementing all of it. TBH, I'd rather contributor to your impl than have my own. I just need a convenient way to swap out the grpc.io dependencies for PBJ ones.

I went through the code, and I don't see much opportunity for reuse. GrpcProtocolHandler is very grpc.io specific, from the compression/decompression to observers and the rest. In this case, I think the best path is for me to continue with a separate implementation.

Thoughts?

[spericas]

@rbair23 Yes, we currently depend on those libraries. Perhaps we can think about creating an SPI to plugin either protoc/grpc.io or a library like yours. This was clearly not a design goal for us at this time, but perhaps something like that can be considered going forward.