taskvine worker binary copy breaks because it belongs to multiple work flows

[benclifford]

Describe the bug

If I run two parsl-perfs in quick succession, or two taskvine workflows at once, I get this error at startup of the later workflow:

RuntimeError: Could not execute vine_factory. Exited with status: 1
cp: cannot create regular file '/home/benc/parsl/src/parsl/runinfo/TaskVineExecutor/vine_worker': Text file busy
vine_factory: Could not Access specified worker binary.

I think this is because the ownership of the path runinfo/TaskVineExecutor/vine_worker is unclear: the 2nd workflow expects that it can put whatever worker executable it wants there, but at the same time the 1st workflow expects that whatever vine worker the 1st workflow wants can also be there. The text file busy error is (I think) a unixism for "you can't copy a new executable over the top of an executable that is currently running"

In the "two parsl-perfs in quick succession" situation, when using Parsl block management that is supposed to make sure everything is shut down before the workflow ends - but I guess the vine factory mode I'm using is slightly different there. In the "two vine workflows at once" situation, I don't think it matters which scaling/factory mode is used - this is still an ownership confusion.

To Reproduce

parsl-perf --time 20 --config parsl/tests/configs/taskvine_ex.py  &  sleep 1s; parsl-perf --time 20 --config parsl/tests/configs/taskvine_ex.py

Expected behavior
workflows shouldn't interfere with each other

Environment
my laptop, parsl master 3a256de