Stop relying on `pkg/errors` to handle stack traces

[knz]

Today the stack trace formatting code delegates to pkg/errors/stack.go.

However, that code uses runtime.FuncForPC and emits file paths in the stack trace derived from the raw file name of the source file.

This method is outdated, as the on-disk file name of a given package's source may be different from the package path (due to go mod versioning, reproducible build sandboxes, etc).

The "modern" equivalent is runtime.CallersFrame, which populates runtime.Frame structs with package path-qualified function names.

We want to use that instead.

[kishaningithub]

If we want to just add stack traces this package is pretty good in my opinion

https://github.com/go-stack/stack

@knz What do you think ?

[knz]

No it is too expensive. The expense to translate the list of PC addresses to metadata should only be paid when the error is formatted.

[kishaningithub]

go-stack/stack#30 (comment)

@ChrisHines i think you are working on improvements using the newer golang features. Would you like to pitch in ?

[ChrisHines]

What kind of timeframe are you hoping to resolve this issue?

[knz]

The plans in the errors library is to take over the principles from pkg/errors. There is no time frame.

[StevenACoffman]

How about cribbing from uber-zap's function: https://github.com/uber-go/zap/blob/master/stacktrace.go#L38-L77

uber-go/zap is licensed under the MIT License, while cockroachdb/errors is licensed under the Apache License 2.0

[mitar]

I have made 2 years ago another errors package to provide stack traces gitlab.com/tozd/go/errors, as a spiritual successor to archived pkg/errors. It does not use runtime.FuncForPC, and it provides stack formatting, etc.