feat: paralell tool execution

[jirastorza]

Pull Request Overview

This pull request introduces parallel execution for tool calls in the RAG pipeline to improve performance when multiple tools are invoked simultaneously. The refactoring splits the tool execution logic into separate functions and leverages Python's ThreadPoolExecutor for concurrent processing.

Key changes:

• Refactored monolithic _run_tools function into _run_tool (single execution) and _run_tools (parallel orchestration)
• Implemented parallel tool execution using ThreadPoolExecutor with configurable worker count

[Copilot]

Pull Request Overview

This pull request introduces parallel execution for tool calls in the RAG pipeline to improve performance when multiple tools are invoked simultaneously. The refactoring splits the tool execution logic into separate functions and leverages Python's ThreadPoolExecutor for concurrent processing.

Key changes:

• Refactored monolithic _run_tools function into _run_tool (single execution) and _run_tools (parallel orchestration)
• Implemented parallel tool execution using ThreadPoolExecutor with configurable worker count
• Added error handling with future cancellation to prevent resource leaks on failures

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Robbe-Superlinear]

If chunk_spans is empty, the content field will be {"documents": []}, which might be fine, but might not be.

[Robbe-Superlinear]

We should confirm if retrieve_context can return 0 chunks.

[jirastorza]

I did not change this behavior with respect to the main branch.
Without metadata_filter, I think retrieve_context always returns a list of ChunkSpans, even if they are not that relevant (low similarity). With a metadata_filter applied (f.e. using self-query), the list could be empty.
I don't know if an empty list should be an issue, I find it more correct than retrieving non-relevant chunks for a query that does not have related documents on the database.
Open to discuss this :)
@Robbe-Superlinear

[Robbe-Superlinear]

I agree that retrieve_context should return an empty list when no relevant chunks are found after applying metadata filtering.

However, how should we handle this case in the response? Currently, we return a message like this:

{
    "role": "tool",
    "content": "{documents: []}", 
    "tool_call_id": tool_call.id
}

We could consider a few alternatives for better clarity:
Option 1:

{
    "role": "tool",
    "content": "{documents: [], message: No results found}", 
    "tool_call_id": tool_call.id
}

Option 2:

{
    "role": "tool",
    "content": "{message: No results found}", 
    "tool_call_id": tool_call.id
}

Option 3: We could return None and let the _run_tools function handle empty tool_call responses.