feat(core-api): add IPluginGrpcService type & user-defined type guard

[petermetz]

1. This will be used by the upcoming functionality of the API server that
   allows all plugins to register their own gRPC services as part of the API
   server's own gRPC service.
2. The above mechanism will largely be the same conceptually as the one
   we have for HTTP and SocketIO endpoints already.
3. It is optional for plugins to implement gRPC services and therefore
   the interface is a standalone one instead of being baked into the more
   generic IPluginWebService interface for example.

Signed-off-by: Peter Somogyvari [email protected]

Pull Request Requirements

• Rebased onto upstream/main branch and squashed into single commit to help maintainers review it more efficient and to avoid spaghetti git commit graphs that obfuscate which commit did exactly what change, when and, why.
• Have git sign off at the end of commit message to avoid being marked red. You can add -s flag when using git commit command. You may refer to this link for more information.
• Follow the Commit Linting specification. You may refer to this link for more information.

Character Limit

• Pull Request Title and Commit Subject must not exceed 72 characters (including spaces and special characters).
• Commit Message per line must not exceed 80 characters (including spaces and special characters).

A Must Read for Beginners
For rebasing and squashing, here's a must read guide for beginners.

[RafaelAPB]

@petermetz LGTM. If I may ask, would this service be extendable for protocols like Connect (https://connectrpc.com/docs/node/getting-started/) that are based on gRPC, or we should implement its own service?

[petermetz]

@petermetz LGTM. If I may ask, would this service be extendable for protocols like Connect (https://connectrpc.com/docs/node/getting-started/) that are based on gRPC, or we should implement its own service?

@RafaelAPB Answering in style, question with question... ;-)
Is "Connect" runtime compatible with vanilla gRPC services?
If yes, then "it should just work", otherwise no.

---

To actually provide some useful info: I went and checked their documentation (and the code) and it looks like it could work out of the box because their service registration is based on the same two parameters that vanilla gRPC does (service interface + service implementation goes to the addService method).

I also noticed that they have HTTP translation through an ExpressJS plugin too which is awesome and something that I've been looking into for a while (a few years now...) and it was always a little too complicated for my taste but with this one we could just have it added as a one-liner.

So, what I'll look into is if we could either use both connect and vanilla, or if it even makes sense to just go with connect. The good thing is that I have integration tests that are already passing on my feature branch so I can very easily go and swap out the gRPC server implementation behind that and see if it would work and if it does then we'd get the HTTP translation for free (which is huge IMO)

[RafaelAPB]

ver implementation behind that and see if it wo

Thanks for the insightful response, as always ;) LGTM!