Integrate NeoGo CN into IR node

[roman-khimov]

Is your feature request related to a problem? Please describe.

I'm always frustrated when I have to update NeoFS because it has so many moving parts and links:

One of the problems specifically is IR/CN relationship. On one hand they're different components performing somewhat different tasks and theoretically they could be deployed to different nodes, use different keys and so on. On the other we always have 1:1 relationship between them (for Alphabet), they always use the same key and they're always on the same machine.

Describe the solution you'd like

We can simplify deployment/updates by merging them into one service (binary). IR node would get a ProtocolConfiguration section of the NeoGo config initially, will run an instance of core.Blockchain along with network.Server and consensus.Service inside and IR code itself can be just another service managed by network.Server (see https://github.com/nspcc-dev/neo-go/blob/v0.100.1/cli/server/server.go#L428 also).

IR will then subscribe to events internally via https://pkg.go.dev/github.com/nspcc-dev/neo-go/pkg/core#Blockchain.SubscribeForNotifications and could rely on this channel to always work. Transactions could be pushed via https://pkg.go.dev/github.com/nspcc-dev/neo-go/pkg/network#Server.RelayTxn and https://pkg.go.dev/github.com/nspcc-dev/neo-go/pkg/network#Server.RelayP2PNotaryRequest. Initially I though that RPC configuration can still be useful, but in fact it can be removed, even public networks use 1:1 IR/CN setups, so we can simplify the code wrt this.

Of course we can also have non-Alphabet IR nodes, but those could just run a regular RPC NeoGo instance internally.

Pros:

• no need to manage/configure another service
• CN will always have the right version compatible with IR (no problems with outdated/too new CNs)
• faster CN/IR communication
• more reliable CN/IR communication (this link can't go down)

Cons:

• theoretical scalability issues

Describe alternatives you've considered

The old model as is. But it's hard to manage even in presence of Ansible roles/neofs-adm tools.

Additional context

We'll get this picture instead of the previous one:

Notice that M nodes can be omitted as well in many cases, leaving us with just two binaries.