v5.12.0: Allow wrapping any error code, not just internal errors

• PR #229 adds the function twirp.WrapError(twerr Error, err error) twirp.Error, that returns the same Twirp error but wrapping the original error, that can can be unwrapped later (for example in middleware) using errors.Is or (github.com/pkg/errors).Unwrap.

v5.11.0: Unwrap errors and AddHTTPResponseHeader

• PR #235 adds the ability to use Go 13+ standard library methods errors.Is and errors.As to unwrap errors from Twirp's internal errors. This works for service errors, usually unwrapped on middleware, and also client errors if they fail on the client, for example a context cancelled error. NOTE: client errors can only be unwrapped if the client was generated with Twirp v5.11.0 or above (even if your service is using a different Twirp version). For older versions, you can still use (github.com/pkg/errors).Unwrap.
• PR #227 adds the helper function AddHTTPResponseHeader, that can be used to set multiple values to the response header in the same key.

v5.10.2: Proto import bug fix, error case improvement

• Fixes the issue in #196, where importing a .proto file with the same Go package as the file being generated would not be handled correctly.
• Includes the response body in the error metadata when the response body's error JSON has an invalid Twirp error code to assist with debugging.

v5.10.1: Fix references to net/http in generated code

This patch release fixes a bug where the generated Go code uses an incorrect package name for net/http when the package is aliased.

v5.10.0: ClientHooks

This release includes two PRs:

#198 adds ClientHooks. These are a structure that can be passed to client constructors to hook off of client request lifecycle events. This can be used to build standard tools for logging, monitoring, or authorization steps in all outbound calls.

#201 fixes the Twirp library WriteError function to return an error value instead of swallowing the error.

v5.9.0: New WriteError function, bugfixes

This release includes three changes.

• #192 added a new github.com/twitchtv/twirp.WriteError function to the main Twirp library. This should help users write general code that plays well in a broader Twirp ecosystem.
• #193 fixes Twirp client behavior when a server responds with an error that is JSON-encoded, but not a valid Twirp error. Now, the client should provide a more meaningful error message in this case.
• #191 fixes a documentation comment in github.com/twitchtv/twirp/hooks/statsd.

v5.8.0: New error code for bad serialization

This release adds a new error code, malformed, which the server returns if a client's message is not deserializable without errors. This error gets a 400 HTTP Status Code. This should make it easier to filter out bad hand-written clients from server error monitoring.

This was #182.

v5.7.0: Better panic handling

This release includes two changes to make panics easier to handle in Twirp servers, as well as a minor bug fix to correct #171.

First, panics are now propagated to Error hooks, allowing application owners to add instrumentation around them. Panics will be wrapped with as twirp.Errors, but will support a Cause() error method, so you can use github.com/pkg/errors to retrieve the root cause of errors in hooks. This was implemented in #160.

Second, Twirp servers now flush error responses when panicking, so that clients always get the message, and don't see a broken pipe if the server crashes due to the panic. In addition, Twirp servers now set Content-Length on all responses, so clients can be sure they have received the complete message. This was implemented in #168.

Finally, protoc-gen-twirp now generated correct code for service definitions with no methods. This was implemented in #171.

v5.6.0: New PathPrefix method on generated servers

This release adds a new method to generated servers. They now support a PathPrefix() string method which returns the path that all of their routes are prefixed with. This should let users of Twirp build better libraries around registration of Twirp services.

v5.5.2: Fix code generation for non-camel case messages

This release includes a fix to the generator to support Protobuf messages that are not defined in camel case. For example, messages such as Hat_v1 would have the Go type name HatV1 in the protoc-gen-go generated code, but the Twirp generated code would expect Hat_v1.