[BugFix] Capture query context when use its mem_tracker out of its lifetime (backport #49123)

[mergify]

Why I'm doing

RuntimeFilterWorker may handle a delay runtime filter of a pre-maturely terminating query, so a query context is destructed before the using its query-level mem_tacker in RuntimeFilterWorker. when this mem_tracker is undergoing
desctruction, its parent mem_tracker (e.g. resource_group-level mem_tracker) would be accessed, however, the resource-group-level mem trackers has already been destructed when the resource group is dropped or altered.

Using query-level mem-tracker beyond query context's life time may lead to BE's crash as follows:

*** Aborted at 1722298201 (unix time) try "date -d @1722298201" if you are using GNU date ***
PC: @          0x80cfb60 (unknown)
*** SIGSEGV (@0x0) received by PID 41980 (TID 0x7f0a2fbea700) from PID 0; stack trace: ***
    @          0x5c32442 google::(anonymous namespace)::FailureSignalHandler()
    @     0x7f0da11847f2 os::Linux::chained_handler()
    @     0x7f0da118b5c6 JVM_handle_linux_signal
    @     0x7f0da1181683 signalHandler()
    @     0x7f0da064c630 (unknown)
    @          0x80cfb60 (unknown)
    @          0x4a588d8 starrocks::MemTracker::~MemTracker()
    @          0x2cb1e8a std::_Sp_counted_base<>::_M_release()
    @          0x4ac1d87 starrocks::RuntimeFilterWorker::_receive_total_runtime_filter()
    @          0x4ac4266 starrocks::RuntimeFilterWorker::execute()
    @          0x8146cb0 execute_native_thread_routine
    @     0x7f0da0644ea5 start_thread
    @     0x7f0d9fc5f98d __clone
    @                0x0 (unknown)

What I'm doing:

We need capture query context to prevent it from being destructed, and when a dropping resource_group is used by outstanding query contexts, it would be delayed to be dropped until all its outstanding query contexts are destructed.

Fixes #issue

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.

If yes, please specify the type of change:

• Interface/UI changes: syntax, type conversion, expression evaluation, display information
• Parameter changes: default values, similar parameters but with different default values
• Policy changes: use new policy to replace old one, functionality automatically enabled
• Feature removed
• Miscellaneous: upgrade & downgrade compatibility, etc.

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 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
  • 3.3
  • 3.2
  • 3.1
  • 3.0
  • 2.5

---

This is an automatic backport of pull request #49123 done by [Mergify](https://mergify.com). ## Why I'm doing RuntimeFilterWorker may handle a delay runtime filter of a pre-maturely terminating query, so a query context is destructed before the using its query-level mem_tacker in RuntimeFilterWorker. when this mem_tracker is undergoing desctruction, its parent mem_tracker (e.g. resource_group-level mem_tracker) would be accessed, however, the resource-group-level mem trackers has already been destructed when the resource group is dropped or altered.

Using query-level mem-tracker beyond query context's life time may lead to BE's crash as follows:

*** Aborted at 1722298201 (unix time) try "date -d @1722298201" if you are using GNU date ***
PC: @          0x80cfb60 (unknown)
*** SIGSEGV (@0x0) received by PID 41980 (TID 0x7f0a2fbea700) from PID 0; stack trace: ***
    @          0x5c32442 google::(anonymous namespace)::FailureSignalHandler()
    @     0x7f0da11847f2 os::Linux::chained_handler()
    @     0x7f0da118b5c6 JVM_handle_linux_signal
    @     0x7f0da1181683 signalHandler()
    @     0x7f0da064c630 (unknown)
    @          0x80cfb60 (unknown)
    @          0x4a588d8 starrocks::MemTracker::~MemTracker()
    @          0x2cb1e8a std::_Sp_counted_base<>::_M_release()
    @          0x4ac1d87 starrocks::RuntimeFilterWorker::_receive_total_runtime_filter()
    @          0x4ac4266 starrocks::RuntimeFilterWorker::execute()
    @          0x8146cb0 execute_native_thread_routine
    @     0x7f0da0644ea5 start_thread
    @     0x7f0d9fc5f98d __clone
    @                0x0 (unknown)

What I'm doing:

We need capture query context to prevent it from being destructed, and when a dropping resource_group is used by outstanding query contexts, it would be delayed to be dropped until all its outstanding query contexts are destructed.

Fixes #issue

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.

If yes, please specify the type of change:

• Interface/UI changes: syntax, type conversion, expression evaluation, display information
• Parameter changes: default values, similar parameters but with different default values
• Policy changes: use new policy to replace old one, functionality automatically enabled
• Feature removed
• Miscellaneous: upgrade & downgrade compatibility, etc.

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 is a backport pr