[BugFix] Unschedule global RF timer in PipelineDriver destructor (backport #76252)

[mergify]

Why I'm doing:

A BE/CN aborts during shutdown with std::bad_weak_ptr:

terminate called after throwing an instance of 'std::bad_weak_ptr'
  what():  bad_weak_ptr
  ... starrocks::pipeline::RunTimerTask(void*)
  ... bthread::TimerThread::Task::run_and_delete()
  ... bthread::TimerThread::run()

The global runtime-filter timer (RFScanWaitTimeout) is owned solely by
PipelineDriver::_global_rf_timer, and it is only unscheduled in
finalize(). Queued or blocked drivers that are abandoned when the driver
executor is closed at shutdown are destroyed without going through
finalize(), so the bthread TimerThread — which keeps only a raw pointer to
the task — can still fire on a task whose last owning shared_ptr is already
gone. PipelineTimerTask::doRun() then calls shared_from_this() on the freed
object and throws std::bad_weak_ptr, aborting the process.

This is the abandoned-driver counterpart to the query-context-destruction race
fixed in #73082, which unscheduled only from finalize(). The throwing
shared_from_this() in doRun() was introduced when PipelineTimerTask
became enable_shared_from_this in #72058.

What I'm doing:

• Extract the unschedule into _unschedule_global_rf_timer() and call it from
  both finalize() and ~PipelineDriver().
• The helper moves the shared_ptr into a local so the task stays alive across
  unschedule_and_join(), closing the window where a concurrently running
  doRun() could observe a zero use_count.
• Add unit tests: the destructor unschedules a pending global RF timer, and the
  destructor blocks until an in-flight timer task returns.

Verified: both changed translation units compile cleanly with the project
toolchain (gcc-12, -std=gnu++23), zero diagnostics.

What type of PR is this:

• BugFix
• Feature
• Enhancement
• Refactor
• UT
• Doc
• Tool

Does this PR entail a change in behavior?

• Yes, this PR will result in a change in behavior.
• No, this PR will not result in a change in behavior.

Checklist:

• I have added test cases for my bug fix or my new feature
• This pr needs user documentation (for new or modified features or behaviors)
  • I have added documentation for my new feature or new function
  • This pr needs auto generate documentation
• This is a backport pr

Bugfix cherry-pick branch check:

• I have checked the version labels which the pr will be auto-backported to the target branch
  • 4.1
  • 4.0
  • 3.5

---

This is an automatic backport of pull request #76252 done by [Mergify](https://mergify.com).

[mergify]

Cherry-pick of b0363d9 has failed:

On branch mergify/bp/branch-4.0/pr-76252
Your branch is up to date with 'origin/branch-4.0'.

You are currently cherry-picking commit b0363d9b0e.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Changes to be committed:
	modified:   be/src/exec/pipeline/pipeline_driver.h

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   be/src/exec/pipeline/pipeline_driver.cpp
	both modified:   be/test/exec/pipeline/schedule/pipeline_timer_test.cpp

To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

[mergify]

@mergify[bot]: Backport conflict, please reslove the conflict and resubmit the pr