[4.2] fix: reuse remote backend after early stop

[jiangxinmeng1]

What type of PR is this?

• API-change
• BUG
• Improvement
• Documentation
• Feature
• Test and CI
• Code Refactoring

Which issue(s) this PR fixes

Issue #27757.

What this PR does / why we need it

• reuse the negotiated remote backend after a successful internal early stop such as LIMIT completion
• keep query cancellation, query deadline, and substantive execution failures terminal so their streams are poisoned rather than returned to the pool
• backport main cancellation normalization semantics, including WithTimeoutCause deadline classification and joined-error preservation
• publish EventEnd only for a successful internal early stop; publish EventError for terminal cancellation/failure

No wire-format or timeout-default change is introduced. The normal success path retains an immediate nil-error fast path.

Validation

• TestSuppressRemoteRunCancelError: pass
• TestIssue27757RemoteRunCancellationClassification: pass
• each focused test under -race -count=100: pass
• full pkg/sql/compile: pass
• full pkg/sql/compile under -race: pass
• go vet ./pkg/sql/compile: pass
• git diff --check: pass

[qodo-code-review]

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

[aunjgr]

Reviewed exact head d598e464c597733cf0160019e4c1ac8de1e093b9 against 4.2-dev@635de0535a21807c02ee49f37331406921c7889b. The early-stop path itself is coherent, but the backport has one blocking cancellation-classification gap.

runErr comes from suppressRemoteRunCancelError(s.Proc.Ctx, err), which suppresses any QueryInterrupted/context-canceled result once the pipeline context is done. Unlike the main-line implementation (normalizeScopeRunError(err, pipelineCtx, queryCtx)), it cannot distinguish an internal LIMIT-driven pipeline stop from cancellation of the query context itself. With a real query cancellation, this head therefore sets runErr == nil, skips Proc.Cancel, calls CleanRootOperator as success, calls prepareForLocalCleanup, and allows finishStreamForReuse to ignore the canceled sender context and return the backend through Close(false). Main deliberately keeps that case terminal.

Please preserve the query-vs-pipeline distinction in the 4.2 backport and add the missing control: cancel the query context while RemoteRun is active and assert a terminal cancellation/EventError and poisoned Close(true), alongside the current internal early-stop success/Close(false) case. Substantive errors should remain terminal as well.

[XuPeng-SH]

Reviewed exact head d598e46. Audited the early-stop backend ownership transfer, response termination, cleanup cardinality, pool reuse/generation boundary, and cancellation/error paths (Q1-Q3). The changed tests and green exact-head CI cover the regression without introducing an unbounded wait, retained state, or material hot-path regression. No blocker found.