js: Add JetStreamError with more API response details

[wallyqs]

Follow up from #1044

This adds a JetStreamError interface that exposes from details about the API response when it is one:

// JetStreamError is an error result that happens when using JetStream.
type JetStreamError interface {
	APIError() *APIError
	error
}

To keep it backwards compatible and keep old checks working, instead of defining JetStream errors like this:

ErrJetStreamNotEnabled = errors.New("nats: jetstream not enabled")

They can be defined like the following:

ErrJetStreamNotEnabled JetStreamError = &jsError{apiErr: &APIError{ErrorCode: JSErrCodeJetStreamNotEnabled, Description: "jetstream not enabled"}}

Signed-off-by: Waldemar Quevedo [email protected]

[coveralls]

Coverage decreased (-0.2%) to 85.638% when pulling f7eaca6 on js-api-err into b81c9e7 on main.

[wallyqs]

could add some other conditions to be able signal the client that something is Temporary() here too, for example when there are transient errors such as JSClusterNotAvailable

[wallyqs]

Another idea is to make a more general JetStreamError but that can still unwrap the APIError: https://github.com/nats-io/nats.go/compare/js-api-err2?expand=1

[piotrpio]

I think I like the second approach (form js-api-err2 branch) a little bit more. It is a bit easier to distinguish API error from client JetStream error if the API error is stored on 1 struct field, not mixed together with message. Plus, it makes defining jsError from APIError more concise.

[piotrpio]

1. Converted all JetStream-related errors to jsError
2. Switch from comparing error codes to errors.Is() in JetStream methods
3. Moved errors to a separate file
4. Removed several unused errors

[wallyqs]

More info about errors package features of wrapping and Unwrap can be found here:

• https://pkg.go.dev/errors#pkg-functions
• https://github.com/golang/go/wiki/ErrorValueFAQ

[kozlovic]

LGTM