Add a JSON-RPC request for reserved nodes

[kpp]

Fixes #8147

Adds a reservedPeers rpc call to return peers added/removed through addReservedPeer and removeReservedPeer.

Is there something left for follow-up PRs?

Yes. The work is in progress

[tomaka]

There's a problem in the design:

When you process the JSON-RPC request in the service, you call reserved_peers, which sends a message to the peerset, then you do rx.await.
However in order for rx.await to actually receive something, the peerset has to process the message. And this processing is done in the networking code as well. And this networking code doesn't run because you're blocking with await.
In other words, this will deadlock.

There are two ways I can see to fix that:

• Don't do await immediately, but spawn a background task or create some sort of FuturesUnordered that allows the future to run "in parallel".
• Change the call to reserved_peers to be synchronous and immediately return the list.

The second is IMO a way better solution on principle, but it potentially introduces a race condition in the peerset: if there are some pending AddReservedPeer or RemoveReservedPeer messages in the peerset's channel, they will not be taken into account. I think that this is fine, but we should document it and open an issue.

[kpp]

Change the call to reserved_peers to be synchronous and immediately return the list.

I don't think I can do that, because I can request Peerset asynchronously via PeersetHandle. So there should be some way to sit and block on Receiver.

Don't do await immediately, but spawn a background task

I thought about it, however there is no executors in the dependency list of the crate.

So I would prefer one of the given solutions:

1. Add another background task-stream, poll in in futures::select!{, .map and send message back to sender,
2. Return Vec<String> from Peerset instead of Vec<PeerId> - this will allow us to pass sender without .awaiting.

[tomaka]

don't think I can do that, because I can request Peerset asynchronously via PeersetHandle. So there should be some way to sit and block on Receiver.

You definitely can. The method you added is on the NetworkWorker, which indirectly holds the Peerset (see here, example). Just use &mut self instead of &self and access everything mutably.

[tomaka]

👍

[tomaka]

bot merge

[ghost]

Waiting for commit status.

[ghost]

Bot will approve on the behalf of @tomaka, since they are a team lead, in an attempt to reach the minimum approval count