Optional RPC Server plugin dependency

[AnnaShaleva]

Summary or problem description
For cases like #4161 (comment) we need to provide an ability to disable RPC Server plugin dependency if needed.

For example, dBFT plugin requires StateService for stateroot calculation, but definitely doesn't need RPC Server plugin as a dependency (because RPC should likely be disabled on consensus nodes due to security reasons). However, right now StateService plugin requires RPC Server plugin as a dependency because StateService exposes a couple of RPC methods.

Do you have any solution you want to propose?
For now, there are two possible solutions suggested:

1. One solution is described in Introduce StateRootInHeader #4161 (comment): split StateService plugin into two plugins: plugin A should calculate stateroots, plugin B should expose state-related RPC methods. Then dBFT will be dependent from plugin A only, it won't introduce RPC Service plugin dependency to dBFT.
2. Another solution is suggested by @shargon: decouple RpcMethod attribute implementation from RPC Server plugin and make RPC Server plugin dependency kind of an "optional". So that if RPC Server plugin is installed, then state-related RPC methods of StateService plugin are available, but if RPC Service plugin is not installed, then state-related RPC methods won't be exposed.

Where in the software does this update applies to?

• Plugins

[AnnaShaleva]

I vote for @shargon's solution, it's simple and less invasive.

[vncoelho]

Both solutions are good to me.
I think that, in long term, both of them should be implemented, specially option 1.

For now, before 3.9.0 I think that any of them is good.

[roman-khimov]

Both work for me, but 2 is a bit preferable since it's less invasive and easier to manage.

[Jim8y]

i dont like 2nd solution, easy as it is, but easy and simple should not be our way of working (not to mention its actually not a big deal or big issue or hard issue to fix at all), we should keep consistency, instead of having special case everywhere. simple as it is here, simple as it is there, special case here, special case there, in the end the proejct full of special case and no consistency at all, and when we maintain it, no system design but full of special cases.

[cschuchardt88]

Both work for me, but 2 is a bit preferable since it's less invasive and easier to manage.

Like @Jim8y said, This makes more problems for us. RPC extensions should be just that, "extensions", not a requirement.

We have a messy house of code and don't need more when we are trying to fix and maintain this mess. Like I say all the time. One step forward 10 steps back. So, please do option one. We all need to be on the same page here with system designs, not a rando jumping in and doing their own thing. I been trying to get everyone on the same paper since I been working on NEO and all I get is ignored. No more asking, I'm telling you do the 1st one and split State Service. If not, blocked!

[shargon]

Option B is not a bad design, because option A require 3 plugins, B only will increase the state root functionalities if you installed the rpc server, otherwise, only will have the stateroot, simpler it's easier, for devs and users.

[cschuchardt88]

Option B is not a bad design, because option A require 3 plugins, B only will increase the state root functionalities if you installed the rpc server, otherwise, only will have the stateroot, simpler it's easier, for devs and users.

Plugins do have a built-in communication protocol for talking to one another. So just put them all in RpcServer.

neo/src/Neo/Plugins/Plugin.cs

Lines 241 to 246 in 9b9be47

	/// <summary>
	/// Sends a message to all plugins. It can be handled by <see cref="OnMessage"/>.
	/// </summary>
	/// <param name="message">The message to send.</param>
	/// <returns><see langword="true"/> if the <paramref name="message"/> is handled by a plugin; otherwise, <see langword="false"/>.</returns>
	public static bool SendMessage(object message)

[ajara87]

For me the best option right now is to decouple the RpcMethod attribute into a lightweight abstractions assembly making the RpcServer plugin an optional dependency. In my opinion this approach avoids introducing additional plugins to maintain, keeps StateService as a single module without forcing RPC exposure and minimizes deployment complexity

[cschuchardt88]

So you know just because a plugin is using RcpMethod doesn't mean It needs the RcpServer plugin loaded. Just look at the ApplicationLog

[vncoelho]

Check the implementation of Option 1).

I was carefully with the AI to make this split....aehuahea
So, perhaps there is no change in the logic. I also verified accordingly.

As soon as you guys check that PR I will also proceed with some tests and we can follow to @superboyiii.

I still think that Option B is also good to be implemented, as I said.

But both are good to me and I think that if the PR i created worked we can implement both.