Add per-process network stats

[fearful-symmetry]

What does this PR do?

This is one half of elastic/beats#7461

This adds per-process network stats on linux, taken from /proc/PID/net/netstat and /proc/PID/net/SNMP.
These metrics are the same kind used in the docker module for reporting docker network summary data.

This also includes a filter function, since all the data in the aforementioned two procfs files includes a prodigious amount of metrics.

There's a notable limitation here, which is that the procfs handler we're importing from go-sysinfo can't handle an alternate procfs.

Why is it important?

This is an asked-for feature.

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in CHANGELOG.md

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2022-11-10T20:15:04.736+0000

• Duration: 11 min 25 sec

Test stats 🧪

Test	Results
Failed	0
Passed	184
Skipped	7
Total	191

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

[rdner]

what if 2 maps have the same key, do we check twice?

[fearful-symmetry]

So, these values are only being merged across a given protocol, and in my experience, the kernel won't report the same metric for a given protocol twice, so it should be fine? Not sure how we would recover from that anyway, since it would seemingly be the same metric reported in two different places?

[rdner]

I just realised that checkMaxConn would just do a type cast, it's not really a big deal to run it twice for the same key. So, the current logic is that the second map has a priority over the first if the keys collide, which I think is fine.

[rdner]

I just realised that checkMaxConn would just do a type cast, it's not really a big deal to run it twice for the same key. So, the current logic is that the second map has a priority over the first if the keys collide, which I think is fine.