ETCM-719: Remove header work queue from persisted state and fix final header skeleton size

[ten15bit]

Description

• a previous refactoring moved the block header work queue to sync state to keep it together with the work queues for block bodies and receipts - this had the unintended side-effect that it also got persisted (which we don't want to happen)
• there was a bug that happened under certain conditions when downloading the final header skeleton
  • let's say we still need to download skeleton headers for the range 5100 to 5200 and our max batch size is 30 the request that would be made would have been to get 4 headers with a gap of 30 - so we're actually requesting up to 5220 which the peer might not have. In that case it would send us back only 3 headers which would fail our validation (because we expect 4).
  • improved the logging of outstanding requests: it would sometimes say waiting for [0] requests when it was actually waiting for the header skeleton
• improves the check whether the peer that we're requesting the skeleton headers from has a high enough best block

Proposed Solution

• moved the header work queue out of sync state again
• changed the calculation of limit so it would only request 3 headers in the example above, so the header skeleton would contain headers 5100 to 5190. After that a new skeleton would be requested with one batch of size 10.

Testing

• added a unit test for calculations performed in HeaderSkeleton
• test case to be added to [Etcm 521] Fast sync integration tests #944 (if not covered already)
• full sync with fast-sync enabled on sagano and mainnet

[AnastasiiaL]

the rest I understand and it makes sense 👍