les: move client pool to les/vflux/server

[zsfelfoldi]

This PR refactors the client peer logic for LES servers similarly to how server peer logic was recently refactored on the client side; now all complex peer logic is separated from the protocol implementation and implemented in the vflux subpackages. The NodeStateMachine is only used in these packages and all references have been removed from package les where a very simple serverPeerSet and clientPeerSet are representing the currently active peers. These changes also prepare the codebase in order to make the next steps (specifically the capacity update logic of les/5) easier to deploy.
A fuzzer for vfs.ClientPool is also implemented in this PR which covers most of the vfs package. This fuzzer does much more meaningful testing of the peer logic than fuzzing the NodeStateMachine alone.

Note: vfs.BalanceTracker.BalanceOperation allows atomic balance operations in the sense that the in-memory peer structure will not change between operations. The database storage of the changed balance is not atomic yet, this will be implemented in the next PR that adds the token sale mechanism. This is where this feature will really make sense because the ether balance and token balance needs to be updated atomically.

[rjl493456442]

Is it possible to return the update list from the enforceLimits for further processing? It's weird to save it in the global priority queue object.

[zsfelfoldi]

Maybe it could be made nicer, I need to think a bit about it.

[zsfelfoldi]

Now I think that the temporary state does make sense because in some cases I do call enforceLimits multiple times and decide the next action based on the temporary state resulting from the previous iteration. It was probably hard to follow though how the temporary state works so I added a commit that does some supposedly identical changes that hopefully makes it cleaner. Now the capacity field is not changed until the temp state is committed and there is a tempCapacity so it's always clear what we are operating on.

[rjl493456442]

What's the difference between the a>b and a-b>0?

[zsfelfoldi]

The way they handle numeric overflows. For example, MaxInt64 > MinInt64 but MaxInt64-MinInt64 < 0. If we use the latter type of comparison then the individual priority values are allowed to overflow and "wrap around" the 64 bit range many times as long as the biggest difference between two priorities in the queue at any moment can be expressed in the int64 range. flowcontrol.ClientManager is a good example for this mode where there is a cumulative "buffer recharge integrator" that is continuously being increased and does overflow. rcQueue item priorities are all calculated relative to this value and the difference between any two item priorities fits safely into int64. The first (free clients only) client pool design also did take advantage of this feature but the current priority pool scheme uses absolute values.
This "wrap around" feature requires care to use and until now all prque.Prque-s operated in this mode. Now it's only used if the queue is explicitly created with the NewWrapAround constructor.

[rjl493456442]

It looks dangerous to me. Firstly it introduces this trick into stack, prque very implicitly. Besides are we sure that flowcontrol.ClientManager can handle the overflow properly?

cm.rcLastIntValue += int64(bonusRatio * float64(dt))

It's indeed increased all the time. But when it's overflow, all the relative calculations will be affected.

For example

dtNext := mclock.AbsTime(float64(rcqNode.rcFullIntValue-cm.rcLastIntValue) / bonusRatio)

This value can be a large negative value if the rcqNode.rcFullIntValue is overflowed.

// check whether it has already finished
		dtNext := mclock.AbsTime(float64(rcqNode.rcFullIntValue-cm.rcLastIntValue) / bonusRatio)
		if dt < dtNext {
			// not finished yet, put it back, update integrator according
			// to current bonusRatio and return
			cm.rcQueue.Push(rcqNode, -rcqNode.rcFullIntValue)
			cm.rcLastIntValue += int64(bonusRatio * float64(dt))
			return
		}
		lastUpdate += dtNext
		// finished recharging, update corrBufValue and sumRecharge if necessary and do next step
		if rcqNode.corrBufValue < int64(rcqNode.params.BufLimit) {
			rcqNode.corrBufValue = int64(rcqNode.params.BufLimit)
			cm.sumRecharge -= rcqNode.params.MinRecharge
		}
		cm.rcLastIntValue = rcqNode.rcFullIntValue

Then the lastUpdate will also be the large negative.

[rjl493456442]

IMO, we should fix the overflow in the flowcontrol manager instead of introducing the tricks into the common data structure.

[zsfelfoldi]

This PR reverts to the non-tricky version in most of the cases and does not change the behavior of the client manager. I will change client manager's priority calculation and get rid of thip wrap-around trick altogether in a next PR.

[rjl493456442]

Thanks!

[holiman]

@alisscco please stop adding random approvals to PRs

[rjl493456442]

LGTM

[zsfelfoldi]

@fjl PTAL at the GetState function in NodeStateMachine. It works similarly to the already existing GetField.