Unreleased:
  - The reverse proxy streams both directions.  A request or response
    body is relayed as it arrives instead of being assembled in memory
    first, so its size is no longer bounded by memory -- previously
    anything over 40 MiB was refused outright with 502, and the client
    could not receive a single byte until the origin had sent the last
    one.  The origin's framing now reaches the client unchanged as
    well: a declared Content-Length stays declared and a chunked
    response stays chunked, where before both were recomputed from the
    assembled buffer.  A HEAD accordingly reports the length the
    equivalent GET would have had, rather than 0.

  - Configuration: REQUEST_BUFFER_MAX (and its -u/--max-upload flag)
    now sizes the buffer a request body is relayed through, 256 KiB by
    default, and no longer decides how large an upload may be.  That is
    MAX_REQUEST_SIZE, new, 1 MiB by default.  RESPONSE_BUFFER_MAX is
    the mirror of the first; there is deliberately no mirror of the
    second, since removing the limit on a response is the point of the
    change.

    UPGRADING: a configuration that set REQUEST_BUFFER_MAX (or -u) to
    permit large uploads meant the limit, so where it is set and
    MAX_REQUEST_SIZE is not, MAX_REQUEST_SIZE takes its value.  Such a
    configuration therefore keeps behaving as it did, at the cost of a
    correspondingly large relay buffer; set both explicitly to separate
    them.

  - Timeouts: UPSTREAM_TIMEOUT (60 s) now bounds the time to the
    response *headers* rather than to the whole transfer, since a large
    download legitimately runs for longer than any useful ceiling.  A
    stalled transfer is bounded instead by the new
    UPSTREAM_STALL_TIMEOUT (60 s), which is how long the origin may
    move no bytes in either direction, and which does not run while
    paivana is holding the origin back because the client has not
    caught up.

  - An origin that fails after its response headers have gone out can
    no longer be reported as 502: the status is already on the wire.
    It is reported as a framing error instead -- a declared
    Content-Length that is not met, or a chunked response closed
    without its terminating chunk -- which RFC 9112 section 8.1.2
    requires a client to treat as a failure.  The exception is an
    HTTP/1.0 client receiving a response of unknown length, where the
    close is the framing and truncation cannot be signalled.

  - Requires GNUnet 0.29.0 for GNUNET_CURL_job_add_stream().
