Better failure and timeout handling

When our rendering servers were unavailable or slow, the API could retry a request on several servers, each time with a new time limit, so a request could take several minutes before failing.

Now the API waits at most 90 seconds in total for its rendering servers, including any retry on another server:

• Requests fail sooner. Some requests that used to succeed after long retries now fail with an error instead. Retrying such a request later is safe.
• Timeouts are no longer retried. If a rendering server times out, the request fails, because the render may still be running and a retry would render the screenshot twice. This includes GPU rendering: without fail_if_gpu_rendering_fails, the request falls back to CPU rendering only when the GPU servers are unavailable and enough time is left.
• Large files aren’t cut off. The limit covers waiting for the rendering servers, not transferring the result, so a large PDF or video can finish downloading after it.

Errors are also more consistent:

• Every error the API returns is JSON with error_code, error_message and documentation_url, as described in the errors documentation, including when a rendering server is unavailable.

See the timeout option.