Add information about github.com/pkg/errors

[alex-semenyuk]

At section with Errors Types mentioned only about standart go library errors, but github.com/pkg/errors is popular as well, we can find a lot of references of it at Uber open source repos:
https://github.com/search?q=org%3Auber%20github.com%2Fpkg%2Ferrors&type=code

So propose to add section about it.

The key points in this:

1. errors.Errorf() formats an error message and includes the stack trace. It's an equivalent fmt.Errorf(), but fmt.Errorf() doesn't print stack trace.
2. errors.Wrapf() formats an error message and includes the stack trace. Another error is embedded in the message.
3. The github.com/pkg/errors is no longer actively maintained. The repo has been archived so it is no longer accepting updates, but remains available for use.

[abhinav]

Thanks for the suggestion, @alex-semenyuk!
Sorry, it’s not clear what value the new section would provide.
With the availability of Go 1.13's error wrapping APIs, the functionality in pkg/errors is redundant—except the stack traces.
The maintainers of this style guide have historically advised against stacktrace-based errors, instead encouraging wrapping with fmt.Errorf to add context as needed. This is especially important in performance-critical code because acquiring a stack trace is not cheap¹.
A section dedicated to pkg/errors would not be very helpful since it would just advise use of std errors.

Footnotes

1. With pkg/errors, a common pattern I've seen is if err != nil { return errors.Wrap(err) } on every return site, which will re-capture a similar stack trace over and over again as the error travels up the call stack. ↩

[alex-semenyuk]

@abhinav Thanks for looking.
I think it will be helpful because it brings clarity why prefer to use fmt.Errorf if do not dig into history of wrapping feature and just look at the functionality it might be not so obvious which one prefer. Also thing like stack trace showing might be considered as additional point to use github.com/pkg/errors on first glance, but we can add your note/advice about stack trace based errors:

This is especially important in performance-critical code because acquiring a stack trace is not cheap