fix: remove empty error wrapping

[ritwikranjan]

Description

This pull request includes changes to improve error handling in the pkg/plugin/hnsstats/vfp_counters_windows.go file. The most important changes include modifying the getVfpPortCountersRaw and listvPorts functions to ensure they return appropriate error messages when command execution fails.

Error handling improvements:

• pkg/plugin/hnsstats/vfp_counters_windows.go: Modified the getVfpPortCountersRaw function to return an empty string and wrapped error message when command execution fails.
• pkg/plugin/hnsstats/vfp_counters_windows.go: Modified the listvPorts function to return the command output and wrapped error message when command execution fails.

Checklist

• I have read the contributing documentation.
• I signed and signed-off the commits (git commit -S -s ...). See this documentation on signing commits.
• I have correctly attributed the author(s) of the code.
• I have tested the changes locally.
• I have followed the project's style guidelines.
• I have updated the documentation, if necessary.
• I have added tests, if applicable.

Screenshots (if applicable) or Testing Completed

Please add any relevant screenshots or GIFs to showcase the changes made.

Additional Notes

Add any additional notes or context about the pull request here.

---

Please refer to the CONTRIBUTING.md file for more information on how to contribute to this project.

[rbtr]

Previously it used to return non-nil empty error even on success.

That's not how errors.Wrap works.

https://github.com/pkg/errors/blob/614d223910a179a466c1767a985424175c39b465/errors.go#L181-L196

// If err is nil, Wrap returns nil.

https://go.dev/play/p/vwqlw1j27tp

[timraymond]

Previously it used to return non-nil empty error even on success.

I'm sorry that my own misunderstanding memed this into existence, but honestly the proposed changes read better in my eyes, even if the two are isomorphic. Nothing magical is happening and the error path is neatly separated from the happy path.

[rbtr]

Previously it used to return non-nil empty error even on success.

I'm sorry that my own misunderstanding memed this into existence, but honestly the proposed changes read better in my eyes, even if the two are isomorphic. Nothing magical is happening and the error path is neatly separated from the happy path.

I agree, but if we observed non-nil, empty errors and thought that this was the cause - it's not. This isn't the fix and the bug is elsewhere.