For sharedmain zap's Fatal should deterministically calculate the POSIX return code

[cardil]

/area test-and-release
/kind feature

Actual Behavior

The Zap's Fatal method is calling os.Exit(1) regardless of a message. This isn't the best UX choice. The POSIX return code could be used for quick assessment about a process failure. When the retcode is always equal 1 for any error, this can't be utilized.

Tools like Docker or Kubernetes report back the return code of the process. By using a deterministic algorithm to calculate the POSIX return code, a quick debugging is possible. Users could indicate if the process is failing because of the same reason, without looking into logs.

Expected Behavior

The best would be to rely on Fatal's message or on an error object if it's attached as a Field.

Additional Info

Related to uber-go/zap#1086

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[dprotaso]

Going to close this out - see the comments on the PR. I think this will be confusing for users as certain exit codes have specific meanings.

I think the better approach would be to ensure we write to the k8s termination path

see: https://kubernetes.io/docs/tasks/debug/debug-application/determine-reason-pod-failure/