Description
Currently when handling a block request we append the newly requested block ids to the queue of previously requested ones, which makes it impossible for the peer to "change its mind" about what blocks it wants to download. Also, because the queue has a size limit, the peer has to download previously requested blocks before even making a new block request.
At this moment this is not an issue, because nodes never send a block request until the previous one is fulfilled. However, in the future we're going to optimize block downloading and peers will need an ability to cancel downloading a block that has already been downloaded from another peer.
A possible solution might be to make a new block request effectively cancel the previous one, overwriting the corresponding queue instead of appending to it.