p2p/nodestate: ensure correct callback order (#21436)

This PR adds an extra guarantee to NodeStateMachine: it ensures that all
immediate effects of a certain change are processed before any subsequent
effects of any of the immediate effects on the same node. In the original
version, if a cascaded change caused a subscription callback to be called
multiple times for the same node then these calls might have happened in a
wrong chronological order.

For example:

- a subscription to flag0 changes flag1 and flag2
- a subscription to flag1 changes flag3
- a subscription to flag1, flag2 and flag3 was called in the following order:

   [flag1] -> [flag1, flag3]
   [] -> [flag1]
   [flag1, flag3] -> [flag1, flag2, flag3]

This happened because the tree of changes was traversed in a "depth-first
order". Now it is traversed in a "breadth-first order"; each node has a
FIFO queue for pending callbacks and each triggered subscription callback
is added to the end of the list. The already existing guarantees are
retained; no SetState or SetField returns until the callback queue of the
node is empty again. Just like before, it is the responsibility of the
state machine design to ensure that infinite state loops are not possible.
Multiple changes affecting the same node can still happen simultaneously;
in this case the changes can be interleaved in the FIFO of the node but the
correct order is still guaranteed.

A new unit test is also added to verify callback order in the above scenario.
# Conflicts:
#	les/serverpool.go
#	p2p/nodestate/nodestate.go
#	p2p/nodestate/nodestate_test.go

to-merge.txt

@@ -344,45 +344,3 @@ Date:   Mon Sep 14 13:57:28 2020 +0100
 
     js/tracers: make calltracer report value in selfdestructs  (#21549)
 
-commit 4eb92969109184c3ccec426d5190a2c183509f5d
-Author: Zsolt Felföldi <zsfelfoldi@gmail.com>
-Date:   Mon Sep 14 14:01:18 2020 +0200
-
-    p2p/nodestate: ensure correct callback order (#21436)
-    
-    This PR adds an extra guarantee to NodeStateMachine: it ensures that all
-    immediate effects of a certain change are processed before any subsequent
-    effects of any of the immediate effects on the same node. In the original
-    version, if a cascaded change caused a subscription callback to be called
-    multiple times for the same node then these calls might have happened in a
-    wrong chronological order.
-    
-    For example:
-    
-    - a subscription to flag0 changes flag1 and flag2
-    - a subscription to flag1 changes flag3
-    - a subscription to flag1, flag2 and flag3 was called in the following order:
-    
-       [flag1] -> [flag1, flag3]
-       [] -> [flag1]
-       [flag1, flag3] -> [flag1, flag2, flag3]
-    
-    This happened because the tree of changes was traversed in a "depth-first
-    order". Now it is traversed in a "breadth-first order"; each node has a
-    FIFO queue for pending callbacks and each triggered subscription callback
-    is added to the end of the list. The already existing guarantees are
-    retained; no SetState or SetField returns until the callback queue of the
-    node is empty again. Just like before, it is the responsibility of the
-    state machine design to ensure that infinite state loops are not possible.
-    Multiple changes affecting the same node can still happen simultaneously;
-    in this case the changes can be interleaved in the FIFO of the node but the
-    correct order is still guaranteed.
-    
-    A new unit test is also added to verify callback order in the above scenario.
-
-commit a99ac5335c631c72fb0d1142a121520d7cf9a950
-Author: Shude Li <islishude@gmail.com>
-Date:   Mon Sep 14 04:25:15 2020 +0800
-
-    Dockerfile: unexpose port 8547 as GraphQL was merged into HTTP endpoint (#21556)
-