Enable retry on unexpected EOF via retry.TransientErr

tl;dr If you use retry.TransientErr in a retry policy, then unexpected end-of-file errors will be treated as transient errors and retried.

• Added new transient error category transient.UnexpectedEOF.
• Classify io.EOF and io.ErrUnexpectedEOF as transient.UnexpectedEOF with the following effects for the retry decider retry.TransientErr:
  • If the underlying Doer.Do(...) method fails as a result of an io.EOF, for example if a remote load balancer decides to throttle a TLS handshake by FIN-ning the connection, retry.TransientErr will indicate a retry.
  • If the response body read fails with an io.ErrUnexpectedEOF because the remote host closed the connection before all bytes indicated by the Content-Length response header have been received, retry.TransientErr will indicate a retry.
• (minor) Improve some stale panic messages.
• (minor) Improve some documentation.

Housekeeping release, documentation only

Small documentation tweaks

Small bug fixes and improvements

• Fixed bug where racing.NewStaticScheduler was dropping the first offset.
• Fixed bug where redundant attempts were not correctly given racing.Redundant error if context.Canceled was wrapped.
• Updated documentation for BeforeAttempt event to clarify that event handler must copy-on-write for reference values in the request.
• Deprecated Event.Name in favor of Event.String.
• Re-enabled continuous integration build with Travis.

Update minimum Go version to 1.14.x

• Increments the module minimum Go version from 1.13.x to the correct value, 1.14.x (some test code depends on 1.14.x).
• Fixes the Travis continuous integration build configuration.
• Implements Stringer interface for httpx.Event

Fix an edge case interaction between racing and retry

This release fixes a bug where the result from retry.Times in a wave with more than one attempt racing would depend on the order in which the attempts finished.

Race concurrent requests to improve response time

Version 1.1.0 adds package racing and the racing feature.

With racing, you can make multiple parallel request attempts to satisfy the same logical HTTP request plan, in order to smooth over your dependencies' rough patches. When racing is enabled, racing policies work cleanly and intuitively alongside existing retry and timeout policies.

Race concurrent requests to improve response time (beta)

This beta release fixes several bugs in the new racing feature and increases test coverage.

This a release candidate. If no issues are found, the current code will be released, along with updated documentation, as version 1.1.0 by 3/28/2021.

Race concurrent requests to improve response time (alpha)

This alpha release adds package racing and the ability to use multiple parallel request attempts to satisfy the same request.

API changes are expected to be stable from this point forward, and alpha tag exists mainly to indicate that unit testing and documentation of the new features are incomplete. In addition, there still remain a few flaky test cases where the underlying root cause needs to be diagnosed and fixed.

Initial release, stable API

Fully functional retrying client with flexible timeout policies.