Memory accounting inaccuracies in multi level merge

[ariel-miculas]

Describe the bug

Not enough memory is reserved for the SortPreservingMerge

• track the record batch buffering (even with buffer_size=1 there's one record batch being prefetched by spawn_buffer)
• take into account that for the minimum requirement for two stream merge, we need to reserve 3 record batches because there could be a record batch crossing happening inside one of the streams
• for multi-column sort, take into account the additional overhead of ReusableRows

To Reproduce

No response

Expected behavior

No response

Additional context

No response

[ariel-miculas]

take

[ariel-miculas]

There's also an inconsistency between the pre-reservation done in multi level merge and the reservations in SortPreservingMerge that end up being ignored because a bypass memory pool is used.

[ariel-miculas]

Also borrow this idea from #14748 :

To implement a more accurate memory size estimation for those edge cases, we can first do col->row conversion and measure the memory consumption. (depends on #7053)

except we don't have to do the row conversion since it should have been done in a previous step, figure out how to reuse it.