The last update here was to stop the RDY updates when multiple inflight messages finished and one of them set the reader into backoff state. I'm fairly certain this last logic update here is subject to a similar RDY count stall that we addressed before.

The bug here is checking `backoff_interval` against `start_backoff_interval` instead of `backoff_block`.

The situation

* failed message, entering backoff state
* RDY 1 is sent
* message received, and finished `requeue(backoff=False)`. This will leave the reader in an unchanged backoff state
* at this point the reader is stalled because no additional RDY is sent to the server (`backoff_interval == start_backoff_interval`).

I think the logic to account for finishing multiple message when in backoff state should be something like

```
if backoff_interval and not self.backoff_block[task]:
    set backoff_block = True
    schedule RDY 1
elif start_backoff_block and not self.backoff_block[task]:
     # leaving backoff
     re-set normal RDY count on all connections
```