Add Better Peer Pruning

[nisdas]

What type of PR is this?

Feature Improvement

What does this PR do? Why is it needed?

• Adds in better peer pruning to handle for dynamic inbound limits.
• Handles more important peers better, instead pruning those are not as critical for a node to
  function better.
• Adds unit test for additional peer filtering.

Which issues(s) does this PR fix?

N.A

Other notes for review

[codecov]

Codecov Report

Merging #8501 (470e7c6) into develop (4d28d5e) will increase coverage by 0.01%.
The diff coverage is 81.81%.

@@             Coverage Diff             @@
##           develop    #8501      +/-   ##
===========================================
+ Coverage    58.09%   58.11%   +0.01%     
===========================================
  Files          458      458              
  Lines        32823    32863      +40     
===========================================
+ Hits         19070    19099      +29     
- Misses       10859    10872      +13     
+ Partials      2894     2892       -2     

[farazdagi]

Would it be safer if we don't obtain several locks for the same operation, but have 3 inline function calls:

	go func() {
		s.attesterLock.Lock()
		defer s.attesterLock.Unlock()
		s.attester.Purge()
	}() 

Those calls can be blocking/sequential, of course:

// obtain lock1
// clear cache
// release lock1

// obtain lock2..

Whenever function obtains two locks I feel uneasy, worrying about whether there's some part of the code that holds the second lock, and in a race for the first lock of the function (thus, potentially, resulting in a deadlock).

Since this method is to be used for tests only, it is probably an overkill to worry about such things.

[nisdas]

Good point, even though its a test only function, should still fix it. Patching it now

[farazdagi]

Looks good, approved (if you want to follow the suggestion on multiple locks, will re-approve after the code is updated -- but it is not strictly necessary, so feel free to merge as is).