Enforce Linux pids as pid_t (or i32).

[fnichol]

While this doesn't completely solve the Launcher reaping/log issues, it tries to correct the type mismatch with how we think about process ids in Linux.

The main work was to thread though the notion of a Pid alias type which was already present in the Windows implementation which helped to keep the calling functions basically generic enough.

One small wrinkle which may not be the best is that I made the protocol level representation an int64. Why? Because in Linux we are dealing with an int32 and this fits in without overflow just fine. On Windows, the pid is a uint32 which also fits into the int64. There are only 2 issues in my mind here: 1) there's a bit of casting going into and out of the wire, but since we only ever communicate with ourselves on the same host/kernel, we always know what we expect to find (this is a bit like generics in Java) and 2) I modified an existing protocol type, but since this only happens in memory on the host, both sides upgrade in lock step.

Thoughts? Is this useful? I was using a Launch and Supervisor with this change for a week in my Builder development container when working on the builder-worker and I can confirm that I was seeing negative pid numbers with this change, and the abs(pid) was the real, correct pid of the service.

[thesentinels]

Thanks for the pull request! Here is what will happen next:

1. Your PR will be reviewed by the maintainers
2. If everything looks good, one of them will approve it, and your PR will be merged.

Thank you for contributing!

[fnichol]

Nice, it looks like this work pre-dated the Docker exporting work in builder-worker. @mwrock do you want me to get the CI fail going, or do you want to take it and rebase? Either way is fine by me.

[mwrock]

I can carry it through @fnichol thanks!

[mwrock]

My commit adds a solution to the launcher reaping issues. The protocol change seems innocent but I'd be curious what others think.

[christophermaier]

[reset]

@mwrock I think the protocol change is ok. Since it's still a 32 bit integer you'll just get integer wrapping at the worst and you're handling it on the Launcher's end. This looks good to me but we should do some testing in acceptance before we push it out :)