feat: lock on Nargo.toml on several nargo commands

[asterite]

Description

Problem

Something mentioned over Slack.

Summary

nargo_cli's build.rs was using a combination of mutexes and file locks. Instead of only doing it there, this PR moves the file lock to almost every nargo command. That means that if you do nargo execute twice on the same directory, the second invocation will wait until the first one ends.

I changed from file_lock to fs2 because it allows doing try_lock_exclusive so we can show the user a message saying we are waiting for a lock...

Additional Context

I didn't include nargo test in here because I think it doesn't produce any output artifact... I don't know if nargo debug should do it either. In any case, for the purpose of tests, I think with having execute and info with a lock is good enough.

Documentation

Check one:

• No documentation needed.
• Documentation included in this PR.
• [For Experimental Features] Documentation to be submitted in a separate PR.

PR Checklist

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.

[github-actions]

Compilation Report

Program	Compilation Time	%
sha256_regression	1.448s	8%
regression_4709	0.832s	5%
ram_blowup_regression	15.180s	2%
rollup-root	3.790s	0%
rollup-block-merge	3.510s	-16%
rollup-base-public	39.900s	-3%
rollup-base-private	19.300s	-4%
private-kernel-tail	1.019s	1%
private-kernel-reset	7.122s	2%
private-kernel-inner	2.194s	5%
noir-contracts	86.500s	-3%

[github-actions]

Execution Report

Program	Execution Time	%
sha256_regression	0.101s	1%
regression_4709	0.001s	0%
ram_blowup_regression	0.592s	1%
rollup-root	0.125s	0%
rollup-block-merge	0.126s	-3%
rollup-base-public	2.510s	1%
rollup-base-private	1.670s	-3%
private-kernel-tail	0.023s	0%
private-kernel-reset	0.394s	1%
private-kernel-inner	0.117s	0%

[github-actions]

Execution Memory Report

Program	Peak Memory
keccak256	74.61M
workspace	123.78M
regression_4709	315.92M
ram_blowup_regression	512.47M
rollup-base-public	1.18G
rollup-base-private	831.47M
private-kernel-tail	181.09M
private-kernel-reset	255.18M
private-kernel-inner	214.28M

[github-actions]

Compilation Memory Report

Program	Peak Memory
keccak256	78.48M
workspace	123.71M
regression_4709	422.91M
ram_blowup_regression	1.58G
rollup-base-public	2.80G
rollup-base-private	1.86G
private-kernel-tail	201.72M
private-kernel-reset	716.99M
private-kernel-inner	291.80M

[aakoshh]

Like I said I'd consider using lock_shared for any that read Nargo.toml, but otherwise LGTM!

[asterite]

Like I said I'd consider using lock_shared for any that read Nargo.toml, but otherwise LGTM!

Done! Let me know if it's good now.

[aakoshh]

Looks great! I think it makes sense that you don't want to overwrite artefacts during debug and test, which I suppose could take a long time.