[TempFile] Revert to using `mkstemp` on unix

[roypat]

Summary of the PR

The name generation in TempFile is done by appending a randomly generated string of 6 alphanumeric characters to a prefix-path. This PR changes that implementation back ot using mkstemp on unix systems, to prevent name collisions. This additionally brings it inline with the TempDir implementation in the unix::tempdir module.

It seems that on windows something similar is possible via GetTempFileName, but I am too unfamiliar with the win32 api (and also have no windows machine available for testing) to be confident in implementing that change.

Reason

We encountered spurious failures in tests due to multiple parallel running tests generating the same random file name.

Open Questions

• Does this need a unit test?
• The (now windows-only) implementation of TempDir::new_with_prefix uses .truncate(true), which silently overwrites existing temporary files in the case of a name collision. Should this be changed?

Requirements

Before submitting your PR, please make sure you addressed the following requirements:

• [x] All commits in this PR are signed (with git commit -s), and the commit message has max 60 characters for the summary and max 75 characters for each description line.
• [x] All added/changed functionality has a corresponding unit/integration test.
• [x] All added/changed public-facing functionality has entries in the "Upcoming Release" section of CHANGELOG.md (if no such section exists, please create one).
• [x] Any newly added unsafe code is properly documented.

[roypat]

@andreeaflorescu Do you want to me address your comments by amending the commit that git revert generated, or do you want them in a follow up commit? 😅

[andreeaflorescu]

@andreeaflorescu Do you want to me address your comments by amending the commit that git revert generated, or do you want them in a follow up commit? 😅

I missed the commits history actually. Why do you want to handle this as a revert? It looks like we want to keep some of the functionality from the initial commit (i.e. the part where it works on Windows), so a revert might not be the best path forward in this case. I am opened to being changed my mind 😆 but for me right now it does not make sense to have this as a revert.

[roypat]

@andreeaflorescu Do you want to me address your comments by amending the commit that git revert generated, or do you want them in a follow up commit? 😅

I missed the commits history actually. Why do you want to handle this as a revert? It looks like we want to keep some of the functionality from the initial commit (i.e. the part where it works on Windows), so a revert might not be the best path forward in this case. I am opened to being changed my mind 😆 but for me right now it does not make sense to have this as a revert.

In my head I treated it as a "revert the unix behavior change introduced by commit xxxxxx", but am happy to just treat it as a normal commit that cfgs the current impl to windows and reintroduces the impl from pre- 4e950be27262c19ea90855ec8ec127271aa9a522 on unix. Since it's not a clean revert anyway, that'd result in a cleaner commit history, too.