[BugFix] Fix the mem_tracker use-after-free of UDF (backport #41710)

[mergify]

This is an automatic backport of pull request #41710 done by Mergify.

---

Mergify commands and options

More conditions and actions can be found in the documentation.

You can also trigger Mergify actions by commenting on this pull request:

• @Mergifyio refresh will re-evaluate the rules
• @Mergifyio rebase will rebase this PR on its base branch
• @Mergifyio update will merge the base branch into this PR
• @Mergifyio backport <destination> will backport this PR on <destination> branch

Additionally, on Mergify dashboard you can:

• look at your merge queues
• generate the Mergify configuration with the config editor.

Finally, you can contact us on https://mergify.com

## Why I'm doing:

*** Aborted at 1686120661 (unix time) try "date -d @1686120661" if you are using GNU date ***
PC: @          0x2ce0b61 starrocks::MemTracker::consume()
*** SIGSEGV (@0x0) received by PID 117789 (TID 0x7f9cd0728700) from PID 0; stack trace: ***
    @          0x58f9dc2 google::(anonymous namespace)::FailureSignalHandler()
    @     0x7f9d147ae362 (unknown)
    @     0x7f9d147b28b9 JVM_handle_linux_signal
    @     0x7f9d147a5f78 (unknown)
    @     0x7f9d13ce1390 (unknown)
    @          0x2ce0b61 starrocks::MemTracker::consume()
    @          0x486d328 _ZNSt17_Function_handlerIFvvEZN9starrocks24call_function_in_pthreadEPNS1_12RuntimeStateERKSt8functionIFNS1_6StatusEvEEEUlvE_E9_M_invokeERKSt9_Any_data
    @          0x475fbe0 starrocks::PriorityThreadPool::work_thread()
    @          0x58b97e7 thread_proxy
    @     0x7f9d13cd76ba start_thread
    @     0x7f9d132f841d clone
    @                0x0 (unknown)

After promise->set_value, if runtime state of query is first destructed, then release the memory, the mem_tracker has already been free, so it will be crash here.

What I'm doing:

Release the mem first, and then set promise value.

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