Refactoring preparation: Extract import queue out of Sync.

[the-right-joyce]

Improve the import queue, allow importing blocks without execution.
Long-term it shouldn’t import justifications, we can remove the JustificationImport trait.

[the-right-joyce]

hi @altonen, so here are the main ideas/solutions we had planned for the Sync in general:

• We want to have explicit separate components for different sync modes, i.e. decouple the sync protocol and state machine. Have a state machine controlling which sync mode we should be using.
• Sync should be its own protocol like all the other protocols that are defined on top of sc-network

The state machine would have the following flows:
Disclaimer: we have here no scenarios for the case that those sync. mode fails

Here are details of how each sync. mode would look like:

You can also find all the related issues to this here: https://github.com/orgs/paritytech/projects/18/views/13

[bkchr]

Disclaimer: we have here no scenarios for the case that those sync. mode fails

When sync fails, there is no real solution than let the operator step in. For example, If something like warp sync fails because some block can not be verified, we can not just fall back to initial sync.

While the above images mainly concentrate on the different syncing strategies and how they work on a high level. They also contain some useful information for this issue. Currently in Substrate we have two ways of how blocks get imported, via block authoring and via the import queue. The only difference is that the import queue is verifying the blocks before importing them, after that the code path should be the same. If you take a look the pictures above, we already have added this behavior to syncing. It first verifies headers on announcement and only requests the blocks on successful verification. Verification should only include stuff like checking the seal of the header. Then when the block is imported we could directly forward it to the block import. Block authoring would use the same block import code path in contrast to the current implementation where these code paths are differ a little bit. For Parachains we have another path of where we can receive blocks and that is via pov recovery. This will also benefit from these changes here.

[altonen]

I've started working on this as well, mainly just getting it out of NetworkWorker. Right now it has been moved to ChainSync which is not really in line with what we want to do (long term) but it's a step closer to getting syncing out of sc-network. Maybe I will move it into a separate, standalone task so it would poll itself and expose some interface for ChainSync instead.