Fix memory revoke in TopNRowNumberOperator

[hantangwangd]

Description

Fix #22127 .

TopNRowNumberOperator should not simply return a completed future for startMemoryRevoke() when it's flag finishing is true. That could lead in the problem described in #22127 when events occur in following order:

1. Have successfully executed spilling at least once, so that the spiller is existing.
2. Then handle some new input pages.
3. Next, the finish() method is called by upstream operator, and the flag memoryRevokingRequested is set by MemoryRevokingScheduler.
4. After that, when driver try to execute handleMemoryRevoke(), the error above would appear.

Test Plan

• Existing test case TestDistributedSpilledQueriesWithTempStorage.testRowNumberLimit
• Before this fix, this error almost certain to occur when running the test 2000 times in a loop. After this fix, it never occur again.

Contributor checklist

• Please make sure your submission complies with our development, formatting, commit message, and attribution guidelines.
• PR description addresses the issue accurately and concisely. If the change is non-trivial, a GitHub Issue is referenced.
• Documented new properties (with its default value), SQL syntax, functions, or other functionality.
• If release notes are required, they follow the release notes guidelines.
• Adequate tests were added if applicable.
• CI passed.

Release Notes

== RELEASE NOTES ==

General Changes
* Fix bug with spilling in TopNRowNumber

[rschlussel]

This should have a release note. it fixes a bug with spilling in TopNRowNumber

[hantangwangd]

This should have a release note. it fixes a bug with spilling in TopNRowNumber

OK, done.