Translate HTTP protocol failures into Faraday connection errors

[samuel-williams-shopify]

An HTTP/2 reset after response headers raises Protocol::HTTP2::StreamError during body consumption. It currently escapes the adapter without becoming Faraday::ConnectionFailed, so retry middleware configured for that exception misses the failure.

Translate Protocol::HTTP::Error into Faraday::ConnectionFailed, preserving the original exception as its cause. This common base covers HTTP/1 and HTTP/2 errors, including RemoteError, RefusedError, and StreamError, without enumerating subclasses in the adapter.

The adapter adds no retries. The broader translation includes locally detected protocol errors and does not imply that retrying is safe or useful. The documentation demonstrates an explicit faraday-retry policy for bodyless GET/HEAD requests and explains compounded attempts, request-body replayability, and partial streamed output.

Regression tests retain the response-body failure path using close_write(error) and enumerate concrete cases: RemoteError, HTTP/2 stream resets with INTERNAL_ERROR and CANCEL, RefusedError, HTTP/1 ContentLengthError, HTTP/2 GoawayError, and the common/HTTP1/HTTP2 base errors. Each verifies a successful middleware retry and preservation of the exact original cause. The existing async-http >= 0.99 requirement remains.

Validation: 37 tests passed (192 assertions); RuboCop passed (21 files).

Fixes socketry/async-http#231.

[jakeonfire]

is this somewhat redundant with async-http's internal retries of socket failures? might this cause issues for PUT body streams that may have been drained? i have no qualms with the documentation, just trying to learn 🙂