Calculate region threshold depending on PeerFeatures

[sdbondi]

Description

When a node is determining if a requesting node is in it's region, it takes
the closest n peers that it is aware of and if the node ID is within
that threshold it considers it a neighbouring node. Because there are
nodes on the network that do not perform some network functions (such as
message propagation and store and forward i.e. wallets), there is a
chance that a majority of neighbours are these non-propagating nodes and
'take up space' where propagation nodes could 'fit'.

When calculating the threshold for neighbouring nodes it must take the
features of the nodes it knows about into account.

This PR changes the peer manager to consider COMMUNICATION_NODEs and
COMMUNICATION_CLIENTs independently to ensure a minimum number of
propagation nodes are considered neighbouring.

TODO: PeerFeatures may be too fine-grained and adding unecessary complexity. It possibly should be replaced with PeerRole::FullNode and PeerRole::Client as part of the Sqlite refactor

Motivation and Context

It's likely that some messages are being ignored by nodes because they don't consider a peer within their network region.

How Has This Been Tested?

Added tests for calc_region_threshold

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Feature refactor (No new feature or functional changes, but performance or technical debt improvements)
• New Tests
• Documentation

Checklist:

• I'm merging against the development branch.
• I ran cargo-fmt --all before pushing.
• I have squashed my commits into a single commit.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.

[CjS77]

LGTM