feat: add delta writer for row-level changes

[DAlperin]

Which issue does this PR close?

Closes #2218

What changes are included in this PR?

This PR adds support for row-level changes (inserts, updates, and deletes) to Iceberg tables through a new DeltaWriter implementation. This enables CDC (Change Data Capture), upsert operations, and efficient row-level deletions.

Key Components:

1. RowDeltaAction Transaction (could be supplanted by feat(transaction): add RowDelta transaction action for row-level modi… #2203

   • New transaction type for applying row-level changes atomically
   • Supports both data files and delete files in a single transaction
   • Located in transaction/row_delta.rs

2. Position Delete Writer

   • Writes position delete files for efficient row-level deletions
   • Deletes rows by file path and row position
   • Located in writer/base_writer/position_delete_writer.rs

3. Delta Writer (Combined Writer)

   • Orchestrates data file, position delete, and equality delete writers
   • Intelligently routes operations based on row tracking
   • Memory-bounded row tracking with configurable limits
   • Falls back to equality deletes for older/evicted rows
   • Located in writer/combined_writer/delta_writer.rs

Input Format:
The DeltaWriter expects RecordBatch with an operations column:

• Value 1 = Insert/Update (write to data file)
• Value -1 = Delete (write to delete file)

Memory Management:

• Tracks recently written rows for efficient position deletes
• Configurable max_seen_rows limit (default: 100,000)
• FIFO eviction when limit is reached
• Can be disabled (set to 0) to use only equality deletes

Are these changes tested?

Unit tests for each new writer are added.

[vustef]

Thanks @DAlperin. I've put some high-level comments. Hoping mostly that @liurenjie1024 has some time to review this or to delegate to some other maintainer who's also more familiar.

[vustef]

Given that his change is bigger, and smaller changes are more manageable, my 2c is to help the other PR (#2203) by reviewing it, and then potentially building upon it.

[DAlperin]

Yeah happy to give that one a review.

[vustef]

The action in the other PR supports deleting data files (I assume for copy-on-write updates and for data file deletes). It'd be good to have that. What do you think?

[vustef]

I'm curious what is @liurenjie1024's opinion on where this thing should live.

This is higher level API than e.g. position delete writer or equality delete writer. It is not the only possible choice of combining these (e.g. some might want to switch to copy-on-write if more than 10% of file is changed, alike to Snowflake's heuristic here: https://docs.snowflake.com/en/user-guide/tables-iceberg-manage#usage-notes-for-deletion-vectors). Therefore, it might not generalize well, and perhaps it should either be part of some other crate, or perhaps structured in a way so that there's a factory of different higher-level writers based on different strategies, possibly extensible outside of iceberg-rust.

I still think there's value in this being in this repository, otherwise other people will have a hard time discovering and reusing functionality that they like.

Another thing to note is that if we're writing Iceberg V3 in future, we shouldn't write positional delete files but delete vectors.

[DAlperin]

Yeah, I'm not precious about where it should live but I do think it should live somewhere in this repo. I've talked with several people who all have this shaped problem and basically end up rewriting this same code over and over again.

I will need to refresh my memory on Iceberg v3 but I'll look into that.