v0.2.1

A correctness release for HTTP/1.1 response framing. No behaviour or
performance change against a server that does not send interim responses.

Fixed

1xx interim responses finished the message. An interim response — 103 Early Hints, or 100 Continue in reply to Expect: 100-continue —
completed a request and freed the connection for the next one. When the
interim and the final response arrive in one segment the counts come out
right by accident. When they arrive separately, which is how an early hint
actually arrives, every request was recorded with the interim status and
the run counted twice as many responses as it sent requests: against a
server sending 103 ahead of a 200, v0.2.0 reports 20 requests all with
status 103.

Servers that send early hints in the wild include Cloudflare and Fastly, so
anyone benchmarking through one was getting wrong numbers.

101 Switching Protocols is now rejected outright: the connection stops
being HTTP/1.1 there and a load generator has nothing to switch to.

Transfer-Encoding did not override Content-Length when chunked was
not the final coding. Transfer-Encoding: chunked, gzip alongside a
Content-Length used the Content-Length; the body actually runs to the
end of the connection.

Repeated Content-Length fields took the last value. They are only
allowed to agree; disagreeing ones are rejected now rather than framing the
stream on a guess.

Known limitation

A 2xx response to a CONNECT request is a tunnel with no body. shb treats
it as close-delimited, so such a request never completes.