bugfix: Fixup race condition when installing near-sandbox

[ChaoticTempest]

Move installing the near-sandbox binary into build.rs as to not contend with multiple tests trying to install it at once.

Fixes: #44

[austinabell]

Won't this still fail if the env variable for the near bin location is unset on first compiling but then set when running? Is the race condition just that the second instance would try to use the binary before it is downloaded and initialized because it passed the check that it exists?

[ChaoticTempest]

Won't this still fail if the env variable for the near bin location is unset on first compiling but then set when running?

The env variable is only used for overriding the location of the binary in the case where the user wants to manually install near-sandbox, so won't matter if its unset then set when running.

Is the race condition just that the second instance would try to use the binary before it is downloaded and initialized because it passed the check that it exists?

it's slightly more interesting: from what I surmised, both instance would try to install at the same time, corrupting the binary. The binary-install already does the job of creating a temp folder and moves over the binary once fully downloaded and extracted, but it doesn't check whether or not the binary was correctly downloaded and only assumed that one instance would touch the temp folder

[austinabell]

it's slightly more interesting: from what I surmised, both instance would try to install at the same time, corrupting the binary. The binary-install already does the job of creating a temp folder and moves over the binary once fully downloaded and extracted, but it doesn't check whether or not the binary was correctly downloaded and only assumed that one instance would touch the temp folder

Then is there something that should be done around making these installations in different locations or having some lock on the file instead of just appending through the download? Is the issue with the move or the download into temp folder (is the temp folder the same?)

I just want to make sure we aren't just doing a band-aid fix that would uncover other issues later if we hit another race condition

[ChaoticTempest]

Is the issue with the move or the download into temp folder (is the temp folder the same?)

the temp folder is the same which is the issue

I just want to make sure we aren't just doing a band-aid fix that would uncover other issues later if we hit another race condition

Good point. Just for good measure then, let me add in a lockfile to lock it from being attempting to install a second binary in the near-sandbox repo. Actually, is there a better way than just having a lockfile?

[austinabell]

Good point. Just for good measure then, let me add in a lockfile to lock it from being attempting to install a second binary in the near-sandbox repo. Actually, is there a better way than just having a lockfile?

What do you mean specifically by having a lockfile? Do you mean using something like fs2 or equivalent, or something else?

[ChaoticTempest]

yeah something like fs2 or equivalent for locking a path or files within that path to not be modified

[ChaoticTempest]

This should fix the issue, and I've opened up near/near-sandbox#21 to address it on the sandbox installation side