Always allocate slots for reserved nodes

[dmitry-markin]

This PR addresses paritytech/polkadot-sdk#533

Probably, similar logic should be implemented for user protocols (non-default peer sets) in polkadot.

[arkpar]

The problem with copying a set of reserved peers on startup is that the reserved peers set can be modified at runtime with RPC calls. Ideally there should be only one instance of that list contained in the peerset. But from what I see this is already a problem in the code with important_peers as well.

@tomaka Is there a good reason for the peerset to be an async interface and not just a simple struct? Perhaps we can simplify things here a lot by making it a simple struct shared with an Arc if required?

[tomaka]

Is there a good reason for the peerset to be an async interface and not just a simple struct?

No, there's no good reason. It was not my decision, and I've always been in favor of making it synchronous. I've tried to make it synchronous in the past, but encountered difficulties which I can't remember.

[dmitry-markin]

So I guess we should refactor peerset interface first to be able to properly handle RPC-added reserved peers?

Does this PR make any sense as it is, or I better close it?

[arkpar]

I think we can merge this for now and if you want to take a stab at refactoring that would be great.

[dmitry-markin]

I think we can merge this for now and if you want to take a stab at refactoring that would be great.

I've created an issue for such refactoring for now. Hopefully I'll be able to do it after other tasks.

[dmitry-markin]

bot merge