Sync cannot download explicitly requested forks as light client if necessary

[rphmeier]

#3633 introduced the beginning of an API for downloading important forks (according to the higher-level consensus algorithm). The problem is that some of these forks may be orphaned or too old for a full node to import.

#3629 is for GRANDPA to use this API

This API should be extended with a parameter where the consensus code can inform sync that it only needs the header-chain. This is the case for GRANDPA. The behavior of the sync code if only the headers are needed should be to:

• attempt to download and import the chain as a full client, if the state of the common ancestor hasn't been pruned.
• otherwise, download only the header chain of the fork. it could go through the client, but doesn't have to, as long as any callers of the sync_fork API receive the header chain.

Importing the header chain via the client (as a "sort-of-light" mode) would be a bit nicer w.r.t. continuity; otherwise if the caller of sync_fork wants to return those headers later on they'll have to maintain their own storage rather than using the shared client utilities.

That needs some investigation as to whether the client can be configured to sometimes act as a light client in import and sometimes not -- @svyatonik any thoughts on that point?

[svyatonik]

If that would be possible, I think that having 'own storage' is a better option. IMO there are many hidden assumptions in the full client code. Like if block just have been imported, its state is available (e.g. to run offchain, ...), its body is available (e.g. to maintain memory pool, ...), ... And if it is possible to localize the code (headers-only import) in a single place, it would be better, imo.

[rphmeier]

Still, it seems cleaner to have it all go through the client. I suppose we could add another BlockOrigin where import notifications aren't fired for such blocks. That should make sure that none of those hidden assumptions (which shouldn't exist in the first place...) get triggered. Either way, if those assumptions are panicking, that is a bug.

[arkpar]

This is implemented in #3942