eth/downloader: fetch blocks in chain order, concurrently with fetch hashes

[karalabe]

Currently the downloader retrieves blocks in a random order due to an unordered underlying fetch queue implementation. This however means that -- statistically -- the entire blockchain needs to be pulled into memory before it's written out to disk, having an O(n) memory complexity, whereas it's possible in O(1). (i.e. if we're aiming for an rpi, this is a must).

On a similar note -- if I'm not mistaking -- all the hashes are retrieved first, and only then does the block downloader start. This should imho be done concurrently, as there is no need to wait for the hashes if there's already something available to pull.

[obscuren]

Priority queue, yes.

Hashes and downloading blocks concurrently, no. This opens up for attack vectors.

[ebuchman]

related to #604, but shouldn't we fetch in incrementing order rather than decrementing from a self-reported (unverified) best TD?

[karalabe]

Closed by #863.