system/process on windows needs to better filter for processes it can't monitor

[fearful-symmetry]

Filing this issue since I'm not a windows person, and I'd probably need some help fixing parts of it. Also shout out to @bjmcnic for his help here.

I've been able to reproduce a number of awkward error messages for system/process under windows, usually error getting process mem for pid and Could not fetch info for PID, all the errors thrown for a variety of PIDs. After some digging, it looks like there's a few different issues going on here:

• OpenProcess when called with a PROCESS_VM_READ flag, will fail when run against privileged system processes.
• OpenProcess calls to fetch metrics from elastic-agent.exe are failing due to the use of PPL by Agent and Endpoint.

Elegant fixes for these issues will require someone with window systems knowledge, and PPL is a can of worms in its own right. Until then, we should at least make the system/process collection on windows a little more intelligent when it comes to failing on processes that we know ahead of time it can't monitor. PIDs 0 and 4 behave in certain weird ways, but we don't have any filter logic here to at least skip over API calls for those PIDs when we know they fail. Similarly, we might want to skip over Permission Denied errors for processes that we know belong to windows services.

[elasticmachine]

Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane)

[softengchick]

#17314

[cmacknz]

Per #17314 (comment) go-sysinfo already handles much of this. I think this is another argument for both switching to go-sysinfo instead of gosigar, and also merging the elastic-system-metrics-package with go-sysinfo elastic/elastic-agent-system-metrics#51

[cmacknz]

I think we can close this now that #17314 is fixed