[to dev/1.3] Remove incorrect timeout reassignment after query planning

[shuwenwei]

The context.setTimeOut() call in QueryExecution.start() mutated timeOut from the total timeout duration to the remaining time after planning. However, all consumers (checkTimeOutForQuery, cleanUpStaleQueries, timeout exception messages) assume timeOut holds the total duration. This caused stale query cleanup to trigger earlier than expected and incorrect deadline values in timeout error messages.

This was already fixed on the master branch by commit fddf0a6 as part of #15031.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 43.50%. Comparing base (458b547) to head (9735c37).
⚠️ Report is 67 commits behind head on dev/1.3.

Additional details and impacted files

@@              Coverage Diff              @@
##             dev/1.3   #18196      +/-   ##
=============================================
+ Coverage      42.61%   43.50%   +0.89%     
+ Complexity       241      198      -43     
=============================================
  Files           3622     3630       +8     
  Lines         240790   243739    +2949     
  Branches       29341    29741     +400     
=============================================
+ Hits          102602   106030    +3428     
+ Misses        138188   137709     -479     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[PDGGK]

Nice catch — this looks right to me. I traced the getTimeOut() consumers to double-check: the runtime deadline checks in FragmentInstanceDispatcherImpl (currentTime - getStartTime() >= getTimeOut()) and the fragment-timeout computations that do getTimeOut() - (now - getStartTime()) (SimpleFragmentParallelPlanner, TableModelQueryFragmentPlanner, …) all treat getTimeOut() as the total duration from getStartTime(), so the post-planning reassignment was effectively subtracting the planning time twice. Removing it restores a single consistent meaning.

One small thought: since several call sites recompute getTimeOut() - (now - getStartTime()) themselves, might a short javadoc on getTimeOut() noting it's always the total-from-start (never "remaining") help keep someone from re-introducing a reassignment like this later? Non-blocking either way.