Prevent starvation by tokio's operation budget

[Ralith]

Tokio's automatic cooperative task yielding feature can cause abruptly prevent a task from making further progress. A very busy connection driver might as a result end up failing to fairly serve transmits or timeouts, resulting in bad behavior (e.g. spurious timeouts or congestion window reduction) under heavy load.

Ideally tokio will expose some tools to arrange for budget fairness across subtasks (e.g. annotations to designate subtasks that should have independent budgets), but if none are forthcoming, we could address this internally by e.g. varying the order we perform operations in by round robin. The current order was chosen for efficiency, however, so an upstream solution is preferred.

[Ralith]

A minimal API to address this appears to have been added in tokio in tokio-rs/tokio#3547.