Perf/randomly drop discovery bucket entry

[asdacap]

• The entry inside the discovery bucket tend to stay fixed and not change. And because we don't do a full dht walk, we are generally limited by the entry within the nodes from the bucket. This causes the percentage of new nodes from neighbour message to stabilize at about 10%.

• This PR add a random drop when a bucket is full which causes the entry in the bucket to change. This reduces the time to reach 8000 candidate node from 40 minute to 5 without increasing the rate of neighbour request.

• This is out of spec, but I guess since the density of the bucket based on the XOR distance stays the same, it should be fine. (bucket with lower distance does not get touched much as its much harder to get node to fill it).

• Run is 20%, 10%, 5%, 2%, no drop, 20%, 10%, 5%, 2%, no drop.
  

Changes

• Fix a lot of random drop of neighbour message.
• Add option to randomly drop last node if bucket is full. Default to 5%.

Types of changes

What types of changes does your code introduce?

• Bugfix (a non-breaking change that fixes an issue)
• Optimization

Testing

Requires testing

• Yes

If yes, did you write tests?

• Yes

Notes on testing

• Works on ewf.
• Mainnet can sync fine.

Requires documentation update

• No

Requires explanation in Release Notes

• Yes: Improved peer discovery

Remarks

• Not sure why not just put it at 20% or 10%. but I guess its not great for the network if the entry keep changing maybe.
• Tried other scheme such as not adding node that is known to be incompatible or drop incompatible peer first. Does not work as effective as just randomly dropping them.

[benaadams]

What if its greater than 16? Is that possible

[asdacap]

In theory. 16 is enough to fix like 99% of unexpected message though.

[benaadams]

I mean should it be:

Suggested change

	if (_lastNeighbourSize + msg.Nodes.Length == 16)
	if (_lastNeighbourSize + msg.Nodes.Length >= 16)