Lsps0 implementation

[JssDWt]

Implement lsps0 server for CLN #104

• Adds custom message receive support to cln_plugin
• Adds custom message send support to cln client
• Adds a server implementation for lsps0, much like grpc.NewServer. You create an lsps0.NewServer(). Then you register the required subservices, in this PR, it contains the ProtocolServer (see lsps0/protocol_server.go). The service has a service implementation and a service description. The service description maps the lsps0 method to the function being called (lsps0.listprotocols). That way, the services can be focused on handling requests and responses, and the lsps0 server wraps these in jsonrpc 2.0 messages over lightning custom messages.
• Adds an integration test for requesting the supported versions over lightning messaging, through the lsps0 protocol.

Note: This PR points to the lsps2 branch. The idea is to create a feature branch with lsps2 changes.

Order of pull requests:

1. (this PR) Lsps0 implementation #114
2. lsps2: implement lsps2.get_versions #115
3. Implement lsps2.get_info #116
4. Implement lsps2.buy #120

[JssDWt]

For an example how to implement a service on top of this, see #115

[JssDWt]

Note: The CLN plugin can no longer be dynamic, because we're setting a feature bit now.

[roeierez]

Looks Great!
The infrastructure and the layer separation looks promising to meet the evolving lsp spec requirements.

[roeierez]

Yes, I think it should be called in go routine otherwise the requests will block each other (in contrary to the grpc server behavior).

[JssDWt]

It now runs in a goroutine. On top of this, there's a mechanism to make sure there are not too many simultaneous requests.

[roeierez]

Why do we need the HandlerType ? Where do we use it?

[JssDWt]

I took it from the grpc service desc. It was used to check the runtime type of the handler passed via RegisterService, whether it implements the interface in the service description. I had removed that check, because I misunderstood it. Reintroduced the check now. Let me know if you think that's a good idea.

[roeierez]

I took it from the grpc service desc. It was used to check the runtime type of the handler passed via RegisterService, whether it implements the interface in the service description. I had removed that check, because I misunderstood it. Reintroduced the check now. Let me know if you think that's a good idea.

I see. As long as we have generic RegisterService underneath then I agree the check is a good idea.
I wonder if we can simplify and add the RegisterXXXServer methods (e.g RegisterProtocolServer) directly as a method of the Server struct and have that type safety check as part of the method prototype.
What do yo think?

[JssDWt]

I wonder if we can simplify and add the RegisterXXXServer methods (e.g RegisterProtocolServer) directly as a method of the Server struct and have that type safety check as part of the method prototype.

I don't see a way to do that without creating a circular reference between the implementing services and the main server, do you have something in mind?

[roeierez]

I see... I now understand that the interfaces are not declared in the base module (lsp0) but every addition introduces its own interface so indeed we can't do it the way I suggested.

[JssDWt]

• Added check for the runtime type of the service implementation
• Make requests run in a goroutine, with a cap on the amount of simultaneous requests
• Rename lsps0.listprotocols to lsps0.list_protocols, as per LSPS0: underscores in method names BitcoinAndLightningLayerSpecs/lsp#49