Fix: scheduler: process remote shutdowns correctly
    
    When unpacking node histories, the scheduler can make multiple passes through
    the node_state entries, because the state of remote node connections (on other
    nodes) must be known before the history of the remote node itself can be
    unpacked.
    
    When unpacking a remote or guest node's history, the scheduler also unpacks its
    transient attributes. If the shutdown attribute has been set, the scheduler
    marks the node as shutting down.
    
    Previously, at that time, it would also set the remote connection's next role
    to stopped. However, if it so happened that remote connection history on
    another node was processed later in the node history unpacking, and a probe had
    found the connection not running, this would reset the next role to unknown.
    The connection stop would not be scheduled, and the shutdown would hang until
    it timed out.
    
    Now, set the remote connection to stopped for shutdowns after all node
    histories have been unpacked.