Following my comment here : #7899 (comment), and related to #7454.

I suggest these changes to improve behavior for streaming use cases:

1. currently, a block could be stuck for 25s. This might prevent streaming where we want blocks to arrive in order, as fast as possible.
2. a slow peer could still request blocks multiple times, even if the requests will timeout every time.

To minimizes these issues, I suggest:

1. reduce timeout to 3s in sequential mode, and reduce request buffer window to target 1s.
2. reverse candidates for slow peer which can not keep up with at least 1 block/second. This way, they will not slow down urgent block requests preventing streaming, while still being helpful (if they do not timeout).

We could introduce a hotswap algorithm (see #7820), but I'm concerned about the added complexity and the amount of cancellations and lost bandwidth. Let me know what you think.

Edit: I need to fix tests