Refactor Sync state logic

[AgeManning]

Description

The logic of calculating the node's current sync is disjoint and exists partly in NetworkGlobals, partly in SyncManager and partly in RangeSync. It makes it difficult to reason about the global sync state of the node and perform upgrades such as #1613.

Instead of refactoring this sync logic, I've decided to keep it as is and make this issue, as there is a sync update PR coming from @divagant-martian and I wanted minimal conflicts.

We are considered sync'd if we are not performing any range sync, and all our peers are considered sync'd with our current head. The split logic comes due to the RangeSync managing its own view of things. There are a number of events that can cause RangeSync to update the sync state, such as RPC errors, peer disconnects, block processing etc. Because of this, the current design was to let RangeSync handle its own sync status.

Perhaps a better solution is to allow the SyncManager to be the source of truth. On all messages it passes to range sync, it could ask RangeSync what it's status is and then based on the response optionally update the global sync status.

If someone takes up this issue, we can discuss the logic of how the global sync status is calculated in this issue :).

[divagant-martian]

starting with this one

[divagant-martian]

closed by #1791