Use net.ConnectionsPidWithContext on FreeBSD, similarly to how it is done
on Darwin. This uses common.CallLsofWithContext underneath the hood, which
will use lsof under the hood, if available.
Tested on FreeBSD 13.2-RELEASE
Signed-off-by: Chris Gianelloni <wolf31o2@blinklabs.io>
e2c79a1 started to blindly set the process name to the full path (instead of the basename) of the cmdline exectuable
if the process name from the process comm was truncated on linux. Python psutil never did that, and this is just wrong
for python (or any executable interpreted script) where the process name is not the interpreter binary but the script
itself.
A new test to check process name value against psutil value is added here, which would hopefully catch any potential
future changes in psutil.
Reverts #542Fixes#1485
Before change:
```
$ GOOS=freebsd GOARCH=386 go build ./process
process\process_freebsd.go:118:26: cannot use k.Start.Sec * 1000 + k.Start.Usec / 1000 (type int32) as type int64 in return argument
```
Removes need for redundant ParentWithContext implementations. It had led
to it being unsupported on FreeBSD and OpenBSD even though
PpidWithContext was available for them, and different implementations
for getting the parent info used in ParentWithContext and
PpidWithContext on Darwin and Linux.
* All context-less wrapping functions (the ones without WithContext
suffix) were moved into process.go since they all are the same.
* Call context is now passed to all underlying functions in
*WithContext() functions.
* All common *BSD bits were moved to process_bsd.go.
* Process.Tgid() method lacked a WithContext counterpart, so
Process.TgidWithContext() was added for uniformity.
* NewProcessWithContext() function was added since NewProcess() is
used a lot throughout the module, and there is no way to pass a
context to it.
This is a part of #761 effort.
This allows for getting more exact information about each argument
especially if there are arguments that have spaces in them.
This was not implemented for darwin or for windows because they
both currently have not way of properly parsing the cmdline string.
Darwin parses the output of 'ps' which is already whitespace
segmented, and windows just has the cmdline string.
Chris Gianelloni