Sipa headersfirst8 patches

[rebroad]

Various changes/fixes.

[sipa]

Thanks! Having these suggested changes as small individual patches is nice.

A few comments in general:

• No problem with the logging improvements; I'll merge those.
• A CaughtUp() function is indeed useful; we're using too many different criteria and implementations for that already.
• Syncheight instead of starting height for invs: makes sense, I'll think a bit harder if there are any pitfalls to that. Getting rid of relying on startingheight is nice, though.
• The stall timeout change: there actually is a bug here, but the problem is not the timeout. It's intended to be in the order of seconds after detecting stalling. However, detecting that stalling in the first place is broken. I thought I had fixed that, but I can't see it in the code, so I'll do it again. Note that stalling is not defined as "this peer is not sending me a block"; it is "we would be able to continue fetching blocks, if not for this peer".
• Don't getdata as soon as the invs are seen: NACK. That means an extra roundtrip for block propagation; that's not acceptable.
• Fix logic for nSyncStarted: I'm not sure what you're trying to fix here.

[sipa]

Regarding the fix logic for nSyncStarted: got it; you want to keep sending out initial header syncs as long as no node has responded with any header. That makes sense, but on a high-latency connection I expect that to result in multiple full header syncs being started from multiple nodes, wasting bandwidth.

[sipa]

I've cherry picked 3 of your logging improvements already into the bitcoin/bitcoin#4468 PR.

[rebroad]

Ok, yes, I now see that the pprev does make sense as otherwise we can't tell if they are ignoring the getheaders request of if they're up to date, or if they're just slow...

[rebroad]

I've added some commits to this that fix the stalled logic, hopefully.

[rebroad]

doh.. I removed the commit that fixed the getheaders from getting loads of headers, thinking you'd patched that, but now it's gone back to downloading tens of thousands of headers again, so I guess you didn't.

[sipa]

Can you rebase and test head? I've made a small change that could affect overzealous stall disconnection.

[rebroad]

@sipa I've made some changes. Please could you have a look at this? It seems to run pretty well so far, but there are still some improvements I'd like to add, such as a fix to make it stop requesting blocks from really slow nodes, and perhaps limiting how many concurrent downloads are allowed.