fix: rust unit test "Text file busy"

[ysndr]

Resolve issues with rust unit tests in models::container_builder::tests::*.

The container builder tests spuriously failed with Text file busy:

thread 'models::container_builder::tests::test_writes_output_to_writer' panicked at flox-rust-sdk/src/models/container_builder.rs:81:54:
called `Result::unwrap()` on an `Err` value: CallContainerBuilder(Os { code: 26, kind: ExecutableFileBusy, message: "Text file busy" })
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::result::unwrap_failed
   3: core::result::Result<T,E>::unwrap
             at /build/rustc-1.73.0-src/library/core/src/result.rs:1077:23
   4: flox_rust_sdk::models::container_builder::tests::test_writes_output_to_writer
             at ./src/models/container_builder.rs:81:9
   5: flox_rust_sdk::models::container_builder::tests::test_writes_output_to_writer::{{closure}}
             at ./src/models/container_builder.rs:76:39
   6: core::ops::function::FnOnce::call_once
             at /build/rustc-1.73.0-src/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Text file busy (26) may occur when executing a script
that is has been written to immediately prior.
This is a known bug in rust (and allegedly other languages)
which is tracked in rust-lang/rust#114554.

We typically see this error in tests, where we write a new container builder script
and immediately execute it within the same process:

https://github.com/flox/flox/blob/main/cli/flox-rust-sdk/src/models/container_builder.rs#L76-L83

In production use, this should not be a problem as the script will be written
by a different process, i.e. pkgdb.

[aakropotkin]

Optional change request. I can do a quick rereview if you do make the change.

[mkenigs]

I saw this flake after 500 runs, which is a lot better. If we decide that's too much at any point, we could use a mutex for any tests that are forking, or run any tests that fork in a single thread

[mkenigs]

nit: the race is caused by threading + forking

[ysndr]

I don't think its due to forking, at least not if this can be attributed to rust-lang/rust#114554.

Even if cargo test runs by forking processes (which I'm not certain about either), each process will write to files in different tempdirs.

[mkenigs]

> This is due to the following sequence of events occuring:
> 
>     1. The main thread opens the file descriptor for writing into `/tmp/executable.sh`.
> 
>     2. The spawned thread calls `fork(2)`, inheriting the file descriptor that has write access to `/tmp/executable.sh`.
> 
>     3. The main thread closes its copy of the file descriptor — but note that it is **not** closed in the child process.
> 
>     4. The main thread then attempts to execute the file. However, because there exists a process with a file descriptor open that has write access to the file, it fails with ETXTBSY and the process panics.

[mkenigs]

cargo test is threading, Command is forking

[ysndr]

Command::spawn == fork() -> exec() that fork, I see..

I think it's clear enough for now, for more detail there is the upstream issue linked as well