This is an automated cherry-pick of #10387

What problem does this PR solve?

Issue Number: close #10337

Problem Summary:

The root cause is in current implementation, the buffered block number in ExchangeSender can be upto max_threads * max_threads * fine_grain_stream_count, so if max_threads is large, and the size of each row is big, the buffered block can consume very large memory.

This pr limit the memory usage of ExchangeSender by max(MAX_BATCH_SEND_MIN_LIMIT_MEM_SIZE * max_threads, max_buffered_bytes_in_executor)

What is changed and how it works?

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
  test in 2-tiflash's cluster, with max_threads = 32 and sort memory limit set to 5G

explain analyze select * from (select *, row_number() over(partition by ps_partkey order by ps_suppkey) as rn from test) d where rn = 10;

Where test has 40000000 rows, each row has ~1200 bytes.
Before this pr
peak memory of each TiFlash is about 30G

[2025/09/01 11:47:48.178 +08:00] [DEBUG] [MemoryTracker.cpp:110] ["Peak memory usage (for query): 33.13 GiB."] [source=MemoryTracker] [thread_id=813]
[2025/09/01 11:47:48.178 +08:00] [DEBUG] [MemoryTracker.cpp:110] ["Peak memory usage (total): 33.13 GiB."] [source=MemoryTracker] [thread_id=813]

After this pr
peak memory of each TiFlash is about 10G

[2025/09/01 11:42:28.895 +08:00] [DEBUG] [MemoryTracker.cpp:110] ["Peak memory usage (for query): 9.86 GiB."] [source=MemoryTracker] [thread_id=635]
[2025/09/01 11:42:28.895 +08:00] [DEBUG] [MemoryTracker.cpp:110] ["Peak memory usage (total): 9.86 GiB."] [source=MemoryTracker] [thread_id=635]

• No code

Side effects

• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Breaking backward compatibility

Documentation

• Affects user behaviors
• Contains syntax changes
• Contains variable changes
• Contains experimental features
• Changes MySQL compatibility

Release note

None