les: implement les4 and UDP extension for token sale

[zsfelfoldi]

This PR implements

• a new module called tokenSale that provides functions (lesPay commands) for depositing funds, buying/selling service tokens, querying prices, balances and connection availability
  • payment channel implementation is not part of this PR, payment receiver is a replaceable module (a dummy testReceiver is included)
  • clients now have a balance in the server's preferred currency (pcBalance) in addition to the already existing service token balance
  • conversion is possible with a dynamically adjusted rate; service tokens are usually held for a short term only
  • a very simple rate limiter logic for lesPay commands protects from DoS attacks while the "recommended delay" feedback makes it easy for clients to behave nicely while still being as efficient as possible
• expiring service token model: like negative balances, now positive service token balances are also decreased exponentially
  • expiration only happens when the clientPool is not filled with priority clients and therefore all service tokens are spendable (kind of a "spendability fee")
  • balanceTracker and the token balance database now use expiredValue which handles exponential decrease without regular updating
  • total existing token amount is limited, the limit is adjusted dynamically based on the availability of free service
  • prices are changed according to the existing token amount to limit ratio
  • this ensures that free service is usually available and tokens are usually all spendable
• improvements to the clientPool:
  • connected clients can be active or inactive, the latter means zero capacity, no request serving but keeping the TCP/IP connection
  • if a higher priority client is connected the lower priority one is not kicked out instantly but deactivated first
  • clients with a positive balance can stay connected as inactive for as long as necessary, free clients are still kicked out after 5-10 seconds
  • inactive clients are waiting in a queue and are automatically reactivated if possible
  • this behavior fits the expiring service token model and the new server pool logic better because token-holding clients want to spend their tokens whenever possible
  • the extra complexity introduced by inactive clients in clientPool will be made up for with a simpler serverPool logic
• les/4 protocol extension with LespayMsg and LespayReplyMsg to provide access to the lesPay commands in-protocol
  • zero-capacity connection is also allowed by les/4 so earlier clients are still dropped instantly
• UDP talkRequest and talkResponse packets are added to discv5 which is used by LES to make lesPay also accessible through UDP when not connected
  • connection pre-negotiation and price queries are much cheaper this way
• PrivateLespayAPI provides user access to the lesPay commands on either the local or a remote server

[rjl493456442]

There is a data race:

• the loop tries to exit and wait the qlock to release channel.
• however is the lock is obtained by another queueCommand call and the cmd is queued in the channel
• loop gets the lock and set nil
• new queued cmd is dropped silently

[holiman]

If these are actual network messages, how come they aren't publically exposed, but only anonymous inlined structs?