Handle missing user database in GetUserNameFromPasswd

[SkyDevLab]

Fixes #119216

Customer Impact

In containerized or minimal Linux environments (such as Docker containers or NixOS builds where /etc/passwd is absent), calling System.Environment.UserName, System.Formats.Tar, or System.IO.Pipes throws an unhandled System.IO.IOException: No such file or directory, causing tools like MSBuild and user applications to crash.

According to the POSIX specification for getpwuid_r, missing user records or a missing user database can return ENOENT ("No such file or directory") or ESRCH ("No such process/user"). Furthermore, the XML doc for GetUserNameFromPasswd explicitly states:

"On success, return a string with the user name associated to the specified UID. On failure, returns an empty string."

Description of Changes

• In Interop.GetPwUid.cs, updated TryGetUserNameFromPasswd to treat errorInfo.Error == Interop.Error.ENOENT and errorInfo.Error == Interop.Error.ESRCH as entry-not-found (username = null; return true;), allowing GetUserNameFromPasswd to return string.Empty as documented.
• Added a unit test in TarWriter.WriteEntry.File.Tests.Unix.cs testing GetUserNameFromPasswd with a non-existent UID (uint.MaxValue), asserting that it returns string.Empty without throwing.
• Added UserName_Unix_DoesNotThrow in Environment.UserName.cs.

Regression

No.

Testing

• System.Private.CoreLib built cleanly with 0 warnings, 0 errors.
• System.Formats.Tar (including Unix build target) built cleanly with 0 warnings, 0 errors.

Risk

Low. Directly fulfills the documented contract of GetUserNameFromPasswd and prevents process crashes in containerized environments.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-io
See info in area-owners.md if you want to be subscribed.

[am11]

There is already a PR up for it #132396.

[SkyDevLab]

Thanks for pointing this out. I wasn't aware that #132396 was already addressing the same issue.

I'll close this PR to avoid duplicating the existing work. Thanks for the clarification!