Errors returned from server should be lowered cased if passed to application

[derekcollison]

I encountered this with invalidating pull requests. The header description is properly title case, but the Go client should lower case it if it passes the string up to the application.

[piotrpio]

@derekcollison I am not sure if that is a good idea. 2 main reasons for that:

1. It may break existing users (e.g. we depend on literal error messages in tests sometimes).
2. It makes some error messages look off, e.g. Exceeded MaxRequestExpires is changed to exceeded maxrequestexpires

Additionally, I'm not sure why is this beneficial - by convention errors in go should start with lowercase, but we always have the nats: prefix anyway.

[wallyqs]

Maybe using errors.Is instead of the error string verbatim is what would have helped here? The nats protocol error implements Is interface and does a ToLower to avoid depending on the case, and the JS APIErrors instead of the error string use the APIError code.

nats.go/nats.go

Lines 2335 to 2337 in 980f955

	func (nerr *natsProtoErr) Is(err error) bool {
	return strings.ToLower(nerr.Error()) == err.Error()
	}

https://github.com/nats-io/nats.go/blob/main/jserrors.go#L143-L154

[piotrpio]

@wallyqs that is not a bad idea, but I'm not sure whether we want to create a new error type here, unless it's something applicable to other errors (basically the whole bunch of errors in nats.go). I think for this scenario it's sufficient to add a new error variable (it can be a JetStreamError I suppose) and return that to be able to easily compare.