Say downstream_timeout covers the connection and processing waits (closes #64)

The waits of up to 10 seconds for an upstream connection and for a
processing slot run inside downstream_timeout, and a request whose
downstream_timeout ends during one gets 500, not 503. The docs now say
so and advise keeping downstream_timeout longer than
upstream_fetch_timeout plus 20 seconds.

Model: opus-5-5

config.example.yml

@@ -74,13 +74,14 @@ upstream_connections_per_host: 20
 # Maximum concurrent connections to all upstream hosts together, on top of
 # the per-host limit (default: 64). A fetch holds its connection until its
 # image has been processed. A fetch that finds none free waits up to 10
-# seconds for one, and if none frees up the request is answered 503.
+# seconds for one, and if none frees up the request is answered 503, unless
+# downstream_timeout has ended first.
 upstream_connections: 64
 
 # Maximum number of images decoded and encoded at once (default: the
 # number of CPUs pixa can use, which follows a container's CPU limit). A
 # request that finds none free waits up to 10 seconds for one, and if none
-# frees up it is answered 503.
+# frees up it is answered 503, unless downstream_timeout has ended first.
 # max_concurrent_processing: 4
 
 # Time allowed for one fetch from an upstream host (default: 30s)
@@ -90,8 +91,10 @@ upstream_fetch_timeout: 30s
 # (1 GiB) (default: 52428800, 50 MiB)
 upstream_max_response_size: 52428800
 
-# Time allowed for answering one client request, the upstream fetch
-# included, so keep it longer than upstream_fetch_timeout (default: 60s)
+# Time allowed for answering one client request (default: 60s). The
+# upstream fetch counts toward it, and so do the waits for an upstream
+# connection and for a processing slot (up to 10 seconds each), so keep it
+# longer than upstream_fetch_timeout plus 20 seconds.
 downstream_timeout: 60s
 
 # The origin a browser lets read pixa's responses, sent as the CORS