alias github.com/pkg/errors to pkgerrors

[poopoothegorilla]

This PR is intended to reduce the burden on reviewing this PR #11818 which aims to reduce the dependency on multierr.

NOTES:

• adds the alias pkgerrors for "github.com/pkg/errors"
• does not aim to change anything else
• will do another round of renaming the rest of the files in another PR
• replace "cosmossdk.io/errors" with "github.com/pkg/errors"

reasons this is good.

• having 3rd party packages share the same alias as standard pkg aliases can lead to assumptions on how pkgs function
• since we intend to replace multierr by using the standard err package we have alot of places where naming collisions happen with github.com/pkg/errors

Avoid unnecessary package name collisions. While packages in different directories may have the same name, packages that are frequently used together should have distinct names. This reduces confusion and the need for local renaming in client code. For the same reason, avoid using the same name as popular standard packages like io or http.
https://go.dev/blog/package-names

[github-actions]

I see that you haven't updated any README files. Would it make sense to do so?

[cl-sonarqube-production]

Quality Gate passed

Issues
5 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
56.5% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[archseer]

pkg/errors should get removed altogether, it's been deprecated for years ever since go improved it's error system. https://github.com/pkg/errors?tab=readme-ov-file#roadmap

[archseer]

(pkgerrors.New -> errors.New, pkgerrors.Wrap(...) -> fmt.Errorf("my text: %v", ...) etc)

Additionally we should deny importing pkg/errors in golangci-lint config.

[jmank88]

pkg/errors should get removed altogether, it's been deprecated for years ever since go improved it's error system. pkg/errors#roadmap

I agree but we have some hold outs for the stack traces that want a replacement.

[jmank88]

(pkgerrors.New -> errors.New, pkgerrors.Wrap(...) -> fmt.Errorf("my text: %v", ...) etc)

Additionally we should deny importing pkg/errors in golangci-lint config.

Is that a thing? I have been hacking on this: #11697

[archseer]

Yep! Denying pkg/errors is even a lint example https://golangci-lint.run/usage/linters/#depguard

[poopoothegorilla]

@archseer do you have any recommendations for how we can replace the stack traces? Thats the big blocker for us taking it out

[jmank88]

@archseer do you have any recommendations for how we can replace the stack traces? Thats the big blocker for us taking it out

I have a hack somewhere that adds file and line number caller info to wrapped errors so that you end with something a little more stacktrace-like.

We still have stacktraces for zap logs at error and above too.