This case induces confusion in the ranks: when the WS connection fails, the result of the run is set to failure then every outstanding response is cancelled.

For `_wait_ready` specifically, because it's a blocking wait on a request it yield a confusing result as the run fails with `CancelledError` and the actual cause (the WS was closed) is lost.

One option would be to `set_exception` on the waiting responses, but I feel like this could create other confusing knock-on effects e.g. more evented waits which currently get ignored might start raising exceptions (although that seems unlikely as callbacks apparently do get called on cancel), and since issues with cancelling only seem to appear in `_wait_ready` that seems like overkill.

Instead have `_wait_ready` handle cancellation by first checking if the result is in error, and using that to raise the underlying error, otherwise retry (and ultimately timeout, probably). And while at it, before signaling a timeout check if the run is in failure and raise that immediately, just in case.

https://runbot.odoo.com/odoo/error/233738