feat: add max-radius param with 5% default

[KolbyML]

What was wrong?

For a larger description of the problem can be viewed here #1574

The TL:DR is currently we start at 100 percent radius when the node will end up at 1-3%. This means we download and purge content our node won't end up storing which wastes a lot of CPU cycles, but also takes our uTP transfer limit which could be used for content within our final 1-3% final radius.

This is a big issue as on the state network, currently we are trying to bridge latest state, but our nodes uTP limit is always full so often trin-execution offer's of state diffs are declined as all State nodes are at transfer capacity.

^ here is a picture I took awhile ago, at the bottom you can see we successfully offered to 0 peers and the content was declined 8 times. This is due to the State nodes being at uTP transfer capacity (or in other words hitting our rate limit)

Recently this issue has gotten worse, but even if it didn't this PR is required if we want to bridge latest state. Bridging state content is very expensive, because there is just so much state to gossip. If we want Portal and the State network to be successful we need a 10x performance improvement at least in Trin as currently Trin can only handle 5 Mbps up and down which is way to slow, we won't be able to take a load on the network with this.

So this PR is the first step in a road of changes which will hopefully greatly increase the performance in Trin. I don't think we have a choice we need to be performent if we want users.

How was it fixed?

Add a cli called max-radius, by default the max radius is 5 percent, assuming we have a network of over 20 nodes we should have max coverage. Since the nodes radius's should end up below 3% especially as the network storage requirements will keep growing over time. So I don't think we should have a default bigger then 5%

For testing on hive we will use --max-radius 100

I think this solution is the best one for the foreseeable future, we could do a more complex scheme but that wouldn't be worth it right now, instead we should focus on finding other bottlenecks in Trin as this PR is good enough and gets us most of want we want for the foreseeable future. A more complex scheme would give diminishing returns, so I wouldn't expect us to look into it until Trin is very optimized so it is a very low priority to further optimize this with a complex solution.