internal/util: Read(U)intFromFile: Return file name in errors

[hoffie]

This PR improves error messages by adding the affected file name. This helps downstream users to locate the source of errors which is useful for e.g. prometheus/node_exporter#1710.

The original error is wrapped as some consumers perform checks on it. The consumers within procfs have been updated to Unwrap the error if necessary.

@pgier @discordianfish What do you think?
cc @SuperQ who was involved with the referenced node_exporter/cpufreq issue.

[discordianfish]

Hrm not sure about the best practices around this but I would assume that if the caller has the filename, there is no need to add it in the error, no?

[hoffie]

Hrm not sure about the best practices around this but I would assume that if the caller has the filename, there is no need to add it in the error, no?

Not sure about best practices either, but it was deemed useful to have the file name somewhere in the user-visible error message in the mentioned ticket regarding the cpufreq collector.

We could also add the information in the caller (e.g. https://github.com/prometheus/procfs/blob/master/sysfs/system_cpu.go#L197), but a quick grep shows that would mean that potentially more places would have to be modified with duplicated code (~14).

If you see benefits in doing that instead, I can modify the PR accordingly.

[discordianfish]

@hoffie Yeah I think we should wrap[1] the error in the caller and add the filename there, even if it's duplication.
But let see what @SuperQ and @pgier thinks?

[1] https://blog.golang.org/go1.13-errors

[discordianfish]

I think #518 superseeds this, so closing