feat(WIP): Add TransactionAction

[CTTY]

Which issue does this PR close?

Related Issues:

• [EPIC] Support for appending data to iceberg table. #1382 [EPIC]
• Add a method in TableCommit to apply changes to TableMetadata to create a new TableMetadata #1386
• Add retry in Transaction::commit method #1387
• Implement saving TableMetadata to new location. #1388
• Swith metadata pointer to new location for different catalogs(sql, hive, glue, etc) #1389

What changes are included in this PR?

Are these changes tested?

[CTTY]

I'm trying to replace update_table with commit_table, also would love some feedback on this:

• Do we actually need TableCommit for catalog to commit tables?
  • In the Transaction we have already staged changes to the current_tablelink.
  • Transaction will need to hold Vec<TransactionAction> so tx itself can rebase updates easily, if needed.
  • Catalogs will need to check if metadata location match and retry based on the check result, TableCommit may be useful in this case, but the logic to apply updates on the base table is still duplicate to Transaction::apply() (https://github.com/apache/iceberg-rust/blob/main/crates/iceberg/src/transaction/mod.rs#L70)

[liurenjie1024]

Left some suggestions.

[liurenjie1024]

pub struct SetLocationAction {
   tx: Option<Transaction>
   location: Option<String>
}

impl SetLocation {
  fn apply(self) -> Result<Transaction> {
   let tx = self.tx.take();
    self.tx.add_action(Arc::new(self));
  }
}

[CTTY]

I tried both tokio-retry2 and backon.

Both will require us toss around an intermediate Error type (RetryError for tokio-retry2 and anyhow::Error for backon). backon integrates better with my existing code, which requires &mut self in the do_commit method. Also, somewhat surprisingly, tokio-retry2 doesn't provide min_delay.

I've chosen to go with backon here but would appreciate any other feedback