downloader: measure successfull deliveries, not failed

[holiman]

Sometimes, during fast-sync, there's this behaviour:

Imported new state entries  count=1556 retry=176  duplicate=527503      unexpected=1463081 
Imported new state entries  count=1536 retry=0    duplicate=527503      unexpected=1463081 
Imported new state entries  count=0    retry=208  duplicate=527544 +41  unexpected=1463248 +167

Where the number of duplicate and unexpected equals the number of retry: 41+167 = 208

Imported new state entries  count=2096 retry=208  duplicate=527544      unexpected=1463248 
Imported new state entries  count=1732 retry=0    duplicate=527544      unexpected=1463248 
Imported new state entries  count=0    retry=176  duplicate=527567 +23  unexpected=1463401 +153

153+23 = 176

Imported new state entries  count=1744 retry=0    duplicate=527567      unexpected=1463401 
Imported new state entries  count=1920 retry=0    duplicate=527567      unexpected=1463401 
Imported new state entries  count=1920 retry=0    duplicate=527567      unexpected=1463401 
Imported new state entries  count=0    retry=208  duplicate=527595 +28  unexpected=1463581 +180

180+28 = 208

The problem

The likely explanation for this is

• We request N items from peer x (at time t0)
• Peer x is slow in delivering them, or delivers only parts of it. We then get those items delivered from another peer.
• In assignTasks, we now assign x with N new items, and request those from him (at time t1)
• Now, peer x delivers the first batch (at time t2). Even though we discard everything as duplicates and unexpected, we still update his throughut measure: he delivered N items in the time t2-t1. While in actual fact, it took him t2-t0 to deliver it.

This PR changes the measurement to look at how many successfull deliveries were made, instead of the total count. A more correct approach would be to look at the correct time for the requests, but that would add a lot more tracking overhead.

Consider this a PoC, I haven't tested it extensively yet.

[karalabe]

LGTM