(IcebergIO) bugfix: wire writeProperties through table create request, not DataWriteBuilder

[clairemcginty]

I discovered when testing a snapshot of #39250 that some properties, like bloom filter enabling, were getting propagated, but non-Parquet-related properties, like write.data.path, were not.

Root cause: writeProperties passed via IcebergIO.writeRows().withWriteProperties(...) were only forwarded to Parquet.DataWriteBuilder.setAll() in RecordWriter, but were never stored as Iceberg table properties. This means:

• Parquet-level properties (e.g., write.parquet.bloom-filter-enabled.column.*) happened to work, because Iceberg's Parquet.WriteBuilder parses them from its internal config map (https://github.com/apache/iceberg/blob/main/parquet/src/main/java/org/apache/iceberg/parquet/Parquet.java#L650-L668) regardless of whether they came from table.properties() or a direct setAll() call.
• Table-level properties (e.g., write.data.path, write.metadata.*) did not work, because they're read from table.properties() by Iceberg's LocationProvider and metadata machinery, not from the Parquet builder's config map.

It turns out that Iceberg's forTable(table) (https://github.com/apache/iceberg/blob/main/parquet/src/main/java/org/apache/iceberg/parquet/Parquet.java#L905-L911) already calls setAll(table.properties()), loading all table properties into the builder's config. So the correct place to apply writeProperties is on the table itself, not as a second setAll() on the builder.

This PR merges writeProperties into the table properties at creation time in both RecordWriterManager.loadOrCreateTable() and WritePartitionedRowsToFiles.loadOrCreateTable().

---

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

• Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
• Update CHANGES.md with noteworthy changes.
• If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI or the workflows README to see a list of phrases to trigger workflows.

[clairemcginty]

cc @ahmedabu98 - I know it's last minute, but would it be possible to get this into the 2.76 release? 🙏

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 58.15%. Comparing base (f2c622b) to head (f347aa2).
⚠️ Report is 19 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff              @@
##             master   #39645      +/-   ##
============================================
- Coverage     58.15%   58.15%   -0.01%     
- Complexity    13085    13089       +4     
============================================
  Files          2521     2521              
  Lines        264850   264862      +12     
  Branches      10788    10788              
============================================
+ Hits         154023   154025       +2     
- Misses       105051   105066      +15     
+ Partials       5776     5771       -5     

Flag	Coverage Δ
java	64.25% <ø> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ahmedabu98]

This PR merges writeProperties and tableProperties into essentially the same thing. I think we should keep them separate.

• table_properties gets applied to a table on creation time
• write_properties applies only to the current execution and takes precedence over tableProperties, but does not actually mutate the table's properties.

This is the behavior I'm seeing with other engines like Flink and Spark as well.

For the issue you're running into, I think you can just supply table properties to the connection. It's not currently exposed in the raw IcebergIO API, but it's in Managed(ICEBERG)

[ahmedabu98]

Removing this makes writeProperties a no-op if the table already exists

[ahmedabu98]

writeProperties are supposed to be execution-scoped. They're not meant to be persisted in the actual table's properties

[github-actions]

Assigning reviewers:

R: @Abacn for label java.

Note: If you would like to opt out of this review, comment assign to next reviewer.

Available commands:

• stop reviewer notifications - opt out of the automated review tooling
• remind me after tests pass - tag the comment author after tests pass
• waiting on author - shift the attention set back to the author (any comment or push by the author will return the attention set to the reviewers)

The PR bot will only process comments in the main thread (not review comments).