Optimize Rust course builder O(n²) cargo refresh problem

[meanmail]

Overview

When building Rust courses with multiple tasks, each attachCargoProject call triggers a full refresh of all projects, leading to O(n²) performance degradation.

Location

File: intellij-plugin/hs-Rust/src/org/hyperskill/academy/rust/RsCourseBuilder.kt
Lines: 121-124 (TODO comment about O(n²) cargo invocations)

Problem

// TODO: attachCargoProject refreshes all projects
//  so in fact there are O(n^2) cargo invocations for n tasks
// Affects both workspace and individual package scenarios

Current implementation calls attachCargoProject for each task, and each call triggers a full refresh of the entire cargo project tree. For a course with N tasks, this results in N × N cargo invocations.

What Makes This Hard

1. Third-party API integration: Must work with IntelliJ Rust plugin's internal APIs (CargoProjectsService)
2. Performance profiling: Need to measure current behavior and prove the improvement
3. Batch operations: Rust plugin's API may not support batch attachment natively
4. State consistency: Must ensure cargo project model stays consistent during batch operations
5. Workspace vs individual packages: Different refresh strategies needed for single workspace vs multi-package projects
6. Testing complexity: Requires real Rust toolchain and multiple task projects to test properly

Requirements

• Profile current implementation to measure and document O(n²) behavior with real numbers
• Redesign to achieve O(n) or O(n log n) complexity
• Implement batch cargo project attachment if possible, or defer refresh to the end
• Handle both workspace and individual package scenarios correctly
• Ensure no regression in functionality (projects still build and check correctly)
• Add performance tests or benchmarks with courses containing 5, 10, 20 tasks
• Document the architectural changes and performance improvements

Success Criteria

• Measurable performance improvement (e.g., 10 tasks: 100 refreshes → 10 refreshes)
• No functional regression in Rust task checking
• Works with both workspace and individual package structures
• Code is maintainable and well-documented

Estimated Time

7-8 hours (includes profiling, implementation, testing with real Rust projects)