Nodes must share their payment_thresholds

[bertllll]

PaymentAdjuster's algorithms that gained strong relations to payment thresholds shed some light on new possible effects of these prospectively user-configurable parameters. We considered them in because we wanted to go close enough to the right scaling of payments whose effect could be that obviously urgent debts would be reduced to their innocent version and so allow continuations operations, while the Node is kept off ban threats, at least for a little longer (if no new funds flow in the wallet).

Previously, we never considered to doubt about our knowledge of any differences between our own payment thresholds and the ones of the other Node in question. There is a reason for that: we've been able to leave this for later as we've known that this real differences are not possible well. We can make them differ in tests but they cannot cause troubles in the production. Still, it seems we need to be ready to include them in our plans. The truth is that in the future we'll always have to remember that our payment thresholds don't necessarily describe the indication lines for our counterpart to consider when our delayed payment needs to be punished by a ban and reversely we our sensitivity could be hard to predict from the other side. If we left the conditions unaltered we'd shoot at our own leg, and everybody in the network would receive damage based on all just guesses and often misunderstandings between our and the other Node's interpretation of these thresholds.

When we decide to begin making this right we should include the thresholds into our NodeRecord and send it around with Gossip. The other Nodes will do the same. Therefore, the payment thresholds will be available in the Neighborhood database and whenever the Account and its PayableScanner approaches running a scan it should ask for the up-to-date thresholds for the Nodes whose accounts qualify for a payment. That means that it's not only a business of the PaymentAdjuster which is a special feature more than otherwise but mainly the main path of the PayableScanner, with every scan. Interestingly, eventually we'll want to fetch actual payment thresholds for every PayableAccount we keep track of in the database, meaning that we'll need to allow that each could have slightly different ones. To implement that we'll need to ask the Neighborhood to provide the thresholds and then provide them to the place where we traditionally evaluate each payable against the thresholds (of now, it always operates only with our own thresholds and is not build to accept any alternative ones).

Challenges:
It's important to be aware that we're talking about maybe the first attempt ever to modify the Gossip protocol. That will require some elevated caution as it is later likely to be referred to as an example for any future design works on the protocol.

Second, it's also important to do some thinking about the factor of runtime changes in the configuration of the thresholds. Even now, when we can unofficially modify them, we can do so only under the constraint that it happens on or before the startup. If we introduce more dynamics into the changes scattered in the Gossip, like the thresholds to be changed in an arbitrary time, we must think also about the time windows open by waiting to receive and process the Gossip with the new information. Will it affect us badly? Probably we need to recon it in a conciliatory manner. Yet, we should have a mechanism in mind how we could help to fight the discrepancies introduced by maybe rare but possible inaccuracies like this.