dex: general purpose go 1.13 error type

[chappjc]

Resolving #483

Based on the DetailedError type

dcrdex/server/db/driver/pg/errors.go

Lines 14 to 38 in ecbeacc

	// DetailedError pairs an Error with details.
	type DetailedError struct {
	wrapped error
	detail string
	}
	// Error satisfies the error interface, combining the wrapped error message with
	// the details.
	func (e DetailedError) Error() string {
	return e.wrapped.Error() + ": " + e.detail
	}
	// Unwrap returns the wrapped error, allowing errors.Is and errors.As to work.
	func (e DetailedError) Unwrap() error {
	return e.wrapped
	}
	// NewDetailedError wraps the provided Error with details in a DetailedError,
	// facilitating the use of errors.Is and errors.As via errors.Unwrap.
	func NewDetailedError(err error, detail string) DetailedError {
	return DetailedError{
	wrapped: err,
	detail: detail,
	}
	}

[chappjc]

Illustrating the purpose of ErrorKind (to avoid the boiler plate of creating a type that defines Error() string), while allowing a const, which errors.New prevents.

[chappjc]

Ready for review, in concept at least, since the new types are not being applied repo-wide.

[JoeGruffins]

Will this be used to clean up https://github.com/decred/dcrdex/blob/master/dex/msgjson/types.go ? Can this also help errors used with the rpc calls, or are int codes %100 necessary?

[JoeGruffins]

If the only thing to wrap is a description, I think fmt.Errorf("%w: description", errFoo) is the same as NewError(errFoo, "description"), but I can see where having other fields would make a separate type needed.

[chappjc]

Will this be used to clean up https://github.com/decred/dcrdex/blob/master/dex/msgjson/types.go ? Can this also help errors used with the rpc calls, or are int codes %100 necessary?

No, I think the msgjson package has different requirements, so I wouldn't change that.