Allow UI to configure --min-hops during runtime

[utkarshg6]

This card is a child of #567 and is blocked by #691.

When Node starts up, the value for --min-hops will need to be passed to all Actors who require it.
This may also include providing a new value if it was changed.

adding --min-hops as a part of the MASQUI-v2 interface so it can be adjusted using the websockets UI interfacing
(#567 was just allowing the CLI command to interact with the database)
@utkarshg6

Modify the Neighborhood's NodeFromUiMessage handler to handle set-configuration messages looking for --min-hops parameters. It should store them in PersistentConfiguration when they arrive, and also set the instance field in the Neighborhood object from #691.

[utkarshg6]

Points mentioned by @dnwiebe in the group chat.

Potential problems with --min-hops:

1. It may be disastrous to set your min-hops count to any more than one more than your highest-min-hops neighbor. The most distant Node you'll find is your neighbor's most-distant Node (his min-hop count) plus your one link to that neighbor. If you insist on more-distant Nodes (old min-hops plus 2 or more), you will be unable to route.

2. For a min-hops increase to be effective, you must receive Gossip about Nodes outside your old patch but inside your new patch. In a well-developed, mature network, you might not receive any Gossip for quite awhile. And until you receive enough Gossip to expand your patch, you will have no exit Nodes that qualify under the new min-hops count.

3. Perhaps it would be better to separate patch size and min-hops, so that a user could increase his patch size without changing his min-hops, monitor his database until it grew large enough to support a larger min-hops, and then increase the min-hops count. He still wouldn't be able to see a patch bigger than the patch of his biggest neighbor plus one.

4. If you reduce your min-hops count, your Node will begin ignoring all Gossip from outside the new, smaller patch. The Nodes around the edges will stay in the database, but will go stale because they will receive no updates from incoming Gossip. This is fine as long as the min-hops count stays small, but if you increase it back to the old value, you'll instantly resume interacting with those stale edge Nodes as if they were fresh. This could be alleviated by a card about trimming the neighborhood database whenever min-hops count is reduced.

5. Much of this, now that I think about it, may be worthless alarmism, because you don't have to pick exit Nodes on the perimeter of your patch. If you have a well-enough-connected Network, you can route around it in a zigzag and rack up a good number of hops without reaching the perimeter.

However, min-hop counts significantly bigger than your biggest neighbor's patch will still probably cut down on the number of exit Nodes that are available to you.

[utkarshg6]

Testing Guideline

Testing --min-hops parameter using set-configuration command

Ensure that --min-hops value can be changed during runtime using the set-configuration command. The allowed value range is 1 to 6. Validate that the route can be found and the data can be relayed.

1. Positive Tests: For each --min-hops (1-6):

   • Verify route discovery.
   • Confirm successful data relay.
   • Check logs for expected outcomes.

2. Negative Tests 1: Test invalid values (<1, >6, Not a Number):

   • Validate rejection or default behavior.
   • Check for proper error handling.

3. Negative Tests 2: Test whether routes can not be found for small networks with higher min hops:

   • Validate route can be found with a small value but not with a bigger min hops value.

4. Boundary Test: Change value from 1 -> 6 :

   • Verify route discovery.
   • Confirm successful data relay.
   • Check logs for expected outcomes.