Refactor to prepare whitelist peers

[AureliaDolo]

To prepare for #1946

I mostly created the PeerType variant and refactored a lot accordingly.

In a nutshell, instead of having many not so related indexes, we have now one index and one config per peer type. I tried my best match on peer types and avoid if as much as possible (if you see something other than stuff == PeerType::default() , there may be an underlying issue), and hide complexity is smaller methods.

[AureliaDolo]

A few points before you take a look:

• I didn't worked on the tests yet
• There is still a lot of copy pasting, I had to review in order to see if 1/ I didn't made mistakes 2/ there are some factorization opportunities and how to do them
• I'm not sure AT ALL with what I did with the banned peers
• good luck with the review 🍀

edit: the latter points have been resolved, but you could still use some luck :)

[AureliaDolo]

I'm considedring having more of a hashmap peertype -> peerConnectionCount what do you think ? @massalabs/core-team

But first making things as generic as possible

[AureliaDolo]

And I'm really wondering what to do with the banned variant, I'd happily take any suggestions

[AureliaDolo]

I'm working on fixing the tests, but let me know if you have any suggestions, especially on code readability

[AureliaDolo]

If you have any scenario ideas with whitelist peers, I'd take them.

To do next (maybe in some follow ups, maybe here)

• add a whitelist peer file in the config Add whitelist support #1946
• add a whitelist client/api command Add whitelist support #1946
• document that in the wiki Wiki update after #1946 #2318
• get a cup of tea
• think about how it could be even more generic make peer management by PeerType more generic #2319
• maybe break down the stats by peer type Add storage protocol and bootstrap stats #1312
• if a peer is in the bootstrap list provided to the bootstrap module, it must be bootstrap in peer info db Make bootstrap peers consistent across bootstrap and network #2320
• write moar tests

[yvan-sraka]

My personal belief is we should merge that PR as it since a lot of good refactorings was already done here, and all the items of the checklist you gave should be done as followups issues/PRs!

One last tweak/code change before merging could be to annotate function that share the same pattern but only differ by their types as "mostly duplicated" since they could be refactored in a second pass using generics :)

[AureliaDolo]

One last tweak/code change before merging could be to annotate function that share the same pattern but only differ by their types as "mostly duplicated" since they could be refactored in a second pass using generics :)

I'll move them around yet again to make more sense

[AurelienFT]

@AureliaDolo I have made a proposition to resolve some problems and improve genericity here : #2379 it's based on your PR. I have made a new PR instead of review because the changes suggested are too big.

[AurelienFT]

@AureliaDolo It's possible that my refactor broke some tests. Do you want me to fix this or you will do it ?

[AurelienFT]

As I have work partially on that I'm agree on this new design. Well tested. Nice refactor :)

most points were corrected but I didn't do a whole new pass

[yvan-sraka]

LGTM! That's always a nice thing to use an Enum rather than several conflicting boolean fields, nice refactoring here ✨

[AureliaDolo]

bors merge

[bors]

Merge conflict.

[AurelienFT]

The merge don't change anything related to this PR.

[AureliaDolo]

bors merge

[bors]

Build succeeded:

• build