p2p: dead/solo subnets investigation

[iurii-ssv]

No description provided.

[moshe-blox]

@iurii-ssv @y0sher

Summarizing our convo:

• This is a good direction we'd like to explore
• We should consider switching from discoverOne->filter->connect to discoverMany->rank->selectBest loop (using a scoring function that takes into account how each peer improves our less populated subnets)
• Being too selective in outgoing/incoming connections is (in our estimation) an attack vector, because its easy to fake subnets in discovery and become everyone's #​1 choice, so this change likely requires us to validate subnets claims by peers whereas now we trust them blindly (@y0sher @MatheusFranco99)
• In order to not stray too far off what we know from Ethereum clients (which dont seem to filter much if at all), we should consider being less harsh in filtering incoming connections, and instead focus only on being selective in outgoing conns and rely on proper balancing to cut off the excess.

[iurii-ssv]

focus only on being selective in outgoing conns and rely on proper balancing to cut off the excess (unless anyone can point to why very selective incoming isn't really a risk)

Relevant note, I think at a bare minimum we probably want to have 2 separate maxPeers limit per each of connection-direction (incoming/outgoing), as opposed to a single shared one - because what I observed in my testing is we would get to maxPeers just from incoming connections very fast (and keep getting more and more of them), and hence we won't be able to open much of new outgoing connections (those "discovery" suggest). Even though we trim ~2 connections per 30s or so, it seems new/pending incoming connections quite often take those 2 slots for themselves.

[iurii-ssv]

Closing since #1949 supersedes this one.