constants: add support for sysexits.h exit codes

[cheezedoodle2]

These exit codes are still in use by process managers which inherited behavior expectations of child processes from the early days of BSD.

[mscdex]

I'm not sure it makes sense to add legacy exit code constants like this to node core.

[cheezedoodle2]

I'm not sure it makes sense to add legacy exit code constants like this to node core.

You're right that it doesn't make a lot of sense on its face, and my first thought was to create a module. However, this doesn't work because the situation is:

1. Within a particular environment which is mostly legacy, but also includes modern systems which must be compatible with systems derived from that environment, there are at least three different families of these constants. Two of them are in the same OS, one major semver apart.
2. Because of this, the canonical source for the constant->number mapping is the header files, which in this environment are treated more like config files, because...
3. Getting a native code compiler in the environment that will be running node is effectively impossible if you want to keep using your very expensive support contract to get free(ish) hardware replacements.

I considered building a C preprocessor in a module to extract the constants, but this was 1) significantly more difficult than I thought, because in one case <sysexits.h> pulls in a bunch of other stuff with compiler-specific conditional statements, partly to select the correct family of sysexit codes as mentioned above, and 2) in a case that isn't in production, but I'm told will be in the future, even the header files won't be available at runtime. Due to government SBOM regulations, only the package builder will have access to headers, and the runtime environment will be very stripped down.

[mscdex]

If we are providing explicit values for typings then I don't see why you would need a compiler or sysexits.h?

Even if it varied depending on platform, surely you can just check the platform and make adjustments as needed?

[cheezedoodle2]

Oh, you're right, the typings should be pulling from the symbolic constants in the C header. I'm not sure how to do that, I can't find anything in the tree as a precedent where the .d.ts files are run through the C preprocessor to replace tokens.

I did do some tests where some test applications would try to ask the node interpreter to figure out what environment it's in, then use hard-coded tables to set the constants correctly. This wasn't reliable for a bunch of reasons, mainly because application security restrictions (100% normal for this platform) prevent the application from directly getting that information from the executive (like a kernel syscall). I can try to infer it by probing another peer image and examining edge cases to drive a heuristic to figure out what the environment probably is, but it's a fragile and only mostly reliable solution at best.