feat: target build optimization for merge into

[JackTan25]

I hereby agree to the terms of the CLA available at: https://docs.databend.com/dev/policies/cla/

Summary

This pr waits for #13950
import new hashtable with blkinfo for target build merge into, it benefits:

• 1. we can reduce IO when we do merge into operations.
• 2. when there are multi rows matched, we can return an error early.
     old implementation:

now we will kill the red load part.

The design and usage:
This Index can be only used for target build merge into (both standalone and distributed mode, but for this pr we just support standalone).

Advantages:

• Reduces redundant I/O operations, enhancing performance.
• Lowers the maintenance overhead of deduplicating row_id.(But in distributed design, we also need to give rowid)
• Allows the scheduling of the subsequent mutation pipeline to be entirely allocated to not matched append operations.

Disadvantages:

• This solution is likely to be a one-time approach (especially if there are not matched insert operations involved),
  potentially leading to the target table being unsuitable for use as a build table in the future.
• Requires a significant amount of memory to be efficient and currently does not support spill operations.
• for now we just support sql like below:
  merge into t using source on xxx when matched then update xxx when not macthed then insert xxx.

Future Enhancement

the others case we need to enhance:

• if there are multi matched clauses we need to push up the conditions
• if there is only one matched update but it has condition.
• distributed mode, unmatched partial modified block offsets merge and pipeline construct.

Pr Design

• We import a new component called BlockInfoIndex for hash table. If we don't trigger spill, we will put all data in
  chunks. For target table as build side, we will read all data blocks from target table. But chunks will merge some blocks into a larger chunk. So we will get the layout like below:

/// the segment blocks are not sequential,because we do parallel hashtable build.
/// the block lay out in chunks could be like belows:
/// segment0_block1 |
/// segment1_block0 |  chunk0
/// segment0_block0 |
///
/// segment0_block3 |
/// segment1_block1 |  chunk1
/// segment2_block0 |
///
/// .........

So we use BlockInfoIndex to maintain an index for the block info in chunks.

pub struct BlockInfoIndex {
    // the intervals will be like below:
    // (0,10)(11,29),(30,38). it's ordered.
    intervals: Vec<Interval>,
    prefixs: Vec<u64>,
    length: usize,
}

And we can use BlockInfoIndex to find out the partial modified blocks quickly:

    /// we do a binary search to get the partial modified offsets
    /// we will return the Interval and prefix. For example:
    /// intervals: (0,10)(11,22),(23,40)(41,55)
    /// interval: (8,27)
    /// we will give (8,10),(23,27), we don't give the (11,12),because it's updated all.
    /// case1: |-----|------|------|
    ///            |-----------|
    /// case2: |-----|------|------|
    ///              |------|
    /// case3: |-----|------|------|
    ///                |--|
    /// case4: |-----|------|------|
    ///              |--------|    

Optimiaztions tracking: #12595

Tests

• Unit Test
• Logic Test
• Benchmark Test
• No Test - Explain why

Type of change

• Bug Fix (non-breaking change which fixes an issue)
• New Feature (non-breaking change which adds functionality)
• Breaking Change (fix or feature that could cause existing functionality not to work as expected)
• Documentation Update
• Refactoring
• Performance Improvement
• Other (please describe):

---

This change is 

[Dousir9]

The part about hash join looks good to me.