Adjust node hop counts with UI messaging

[anonmate]

UI messaging so that hop counts can be changed anywhere from 1 hop to 6 hops (unless there is some good reason why 1 hop should not be allowed). A large concern for many users is that 3 hops will be too slow for daily use, and they may not need the privacy 3 hops provides. In this instance, they should be able to choose, and hopefully without restarting the node (although this is not essential).

There is possible 3 places in the code where it needs to be change.
The messaging would need to be configured to be directed into various places in the code.

[dnwiebe]

Suggestion: store the minimum hop count in the PersistentConfiguration.

This will mean a database migration, of course.

It will also mean making the PersistentConfiguration available in the StandardGossipHandler so that it can be used for patch computation. When this modification is made, I suggest the following associated cleanup: modify the qualifies() and handler() trait method signatures so that they take only parameters that change per Gossip package, and make longer-lived data items, like the NeighborhoodDatabase, the CryptDE, and--now--the PersistentConfiguration, instance fields. Consult @bertllll about the lifetime issues that will crop up.

[dnwiebe]

I can't think of a security reason (other than the standard argument that with 1 or 2 hops there's a dangerous amount of knowledge in some or all Nodes) why single-hop should be prohibited, but if it is made part of this card, the way routes are computed will need to change, because since the beginning of Substratum, it has always been the case that next-door neighbors were not acceptable as exit Nodes. That means that if the minimum hop count is reduced to 1 without routing-engine changes, the routing engine will never be able to generate a route.

However, there's also the argument (thanks, @bertllll ) that if you're disinterested enough in privacy to specify 1-hop routes, you'd probably be better off bypassing the Node entirely (except for providing routing and exit services), because at a 1-hop route length, it's essentially equivalent to a slow, complicated VPN, whereas it would be faster to just use a real VPN..

[dnwiebe]

Tasks that I can think of immediately:

1. Add --min-hops to the clap schema and process it into the NeighborhoodConfig in NodeConfiguratorStandardUnprivileged.
2. Add an instance field in the Neighborhood to hold the minimum hop count, and make the Routing Engine actually use the value when calculating routes. (See above comment about single-hop routes.)
3. Make sure it can be used in masq to establish the Daemon's in-memory setup and passed okay to a starting Node.

---

4. Make a place for it in PersistentConfiguration and modify SetupReporter to load it from the database if it isn't specified anywhere with higher priority. Remember to add a database migration for the new configuration property and bump the CURRENT_SCHEMA_VERSION constant.

---

5. 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 Task 2.