feat(debugger): debug test functions

[anaPerezGhiglia]

Description

Expand debugger funcionality to support debugging test functions and configure an external oracle-resolver url.
This will allow to debug contract tests using the TXE as oracle resolver

Problem*

Resolves #5208

Summary*

• Add the possibility to compile and debug a test function
• Add a new config parameter to configure an external oracle resolver when debugging
• REPL: execute the debugger in a separate thread than the repl cli
• Add new Debug test codelens request. Related vscode-noir PR (feat(codelens): trigger debugger on 'Debug test' command (#3) vscode-noir#100))

Additional Context

Debugger changes

• add test-name and oracle-resolver arg options to debugger (both repl and dap interfaces)
• modify DebugForeignCallExecutor to support setting a resolver_url
• modify the debugger to know how to compile a specific function that's not the main function
• create a new DebugExecutionResult enum that represents the possible outcomes of debugging a program
• modify the debugger to expose the execution result once the debug session ends
• add the responsibility of analyzing the execution result once the debugger finishes with the execution to analyze whether the execution matches the test expectations (some test may be marked to should_fail)
• convert ReplDebugger into AsyncReplDebugger
  • this involved spawining a new thread and communicating with the debugger through a mpsc channel
    • this implied moving some responsibility from the _cmd to the debugger mod, and from the repl to the context- like creating the Bn254BlackBoxSolver or restarting the debugging context
  • the async debugger entry points are defined by the DebugCommandAPI enum

Modifications in nargo module

• create a new nargo::ops::debug module. Extract reused debug functions into it.
  The moved functions are mostly about knowing how to compile or prepare the package for compiling for debugging. This also avoids generating inter-dependencies between debug_cmd and dap_cmd
• make some test functions and structs public to be able to use them from debugger cli commands
  • make some nargo::ops::test functions public
  • create TestResult::new function to be able to construct one from dap

Modifications in noirc_frontend::debug module

• Modify the DebugInstrumenter to instrument contract functions in addition to top-level functions

Observations

• This PR is related with feat(codelens): trigger debugger on 'Debug test' command (#3) vscode-noir#100
• This PR is built on top of the changes included in
  • fix(debugger): improve debugger_expected_call_stack test #7769
  • chore(nargo): extract common functions #7957
• For the debugger to work properly when debugging aztec contracts test functions, fix(nargo-rpc): restart http-client on ClientError::Transport error #7954 (or a proper fix) is needed

Documentation*

Check one:

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

Evidence

REPL: Debug simple noir test function

REPL: Debug aztec contract test function

• DAP + VsCode extension: Debug aztec contract test function*

dapDebuggerContractTest.mov

PR Checklist*

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

[github-actions]

Thank you for your contribution to the Noir language.

Please do not force push to this branch after the Noir team have started review of this PR. Doing so will only delay us merging your PR as we will need to start the review process from scratch.

Thanks for your understanding.

[asterite]

Looks great, thank you! I'll merge this tomorrow in case you want to push a couple more things, but it's fine like this too.

[asterite]

@anaPerezGhiglia I think this PR broke something. Look at the difference between ngood (a good nargo 👼) and nbad (the bad nargo 😈):

Note how the ">" character doesn't immediately show up in the bad nargo unless I type something and erase it, or hit enter. And for a reason I still don't understand it makes the debugger_expected_call_stack test fail if run from a different directory.

I'll try to debug this to figure out what changed, but if you have any ideas before I do, please let me know! 🙏

[anaPerezGhiglia]

@asterite one of the main changes for the Repl debugger was that I had to make it async, so that the debugger can wait the ForeignCallResolver call result
So the communication between the REPL cli and the debugger is no longer synchronous - so that must be the root cause of this.
I recall I saw a similar behavior back in the days, but I thought I had solved it - perhaps not, or something got lost in the way
I'll take a look as well

[asterite]

Thank you!

Just now I tried debugging it again and I found something: Status::Idle is sent in the beginning of the loop, so that is received immediately on the other side right after sending the command.

I changed it to send Status::Idle at the end of the loop. Then I also had to change it to not wait for "idle" when terminating. And it seems to work!

I'll send a PR and ask you for an optional review :-)