Core, Spark: RewriteTablePath support for multiple source and destination prefixes

[krisnaru]

What changed

RewriteTablePath today accepts a single source → target location prefix.
This PR generalizes it to support multiple prefix mappings in one run, so a table whose files live under more than one prefix (e.g. data under one bucket/path and metadata under another) can be relocated in a single action.

API

rewriteLocationPrefix(sourcePrefix, targetPrefix) can now be called multiple times — each call registers one mapping:

SparkActions.get()
    .rewriteTablePath(table)
    .rewriteLocationPrefix("s3://old-data/",  "s3://new-data/")
    .rewriteLocationPrefix("s3://old-meta/",  "s3://new-meta/")
    .endVersion("v3.metadata.json")
    .execute();

For every path, the longest matching source prefix wins (RewriteTablePathUtil.lookupPrefixMappings), so overlapping prefixes resolve deterministically. A path that matches no mapping fails fast with a clear error.

Implementation

• Core (RewriteTablePathUtil) — path rewriting is now driven by a
  Map<String,String> prefixMappings. The previous single-prefix public methods
  (replacePaths, rewriteManifestList, stagingPath, newPath, …) are retained as backward-compatible overloads that delegate to the map-based versions, so existing callers keep working.
• Partition statistics — the map-based replacePaths previously rejected tables that had partition-statistics files; that guard was spurious (the code already rewrites those paths), so it is removed and partition-statistics file paths are now rewritten correctly.
• Spark 4.1 — RewriteTablePathSparkAction switched to the prefixMappings map API, resolving the matching prefix per manifest / delete file. This is combined with the rewritten delete-file size tracking already on main.

Scope

Multi-prefix support is exposed in Spark 4.1 only for now. Spark 3.5 and 4.0
are unchanged and continue to compile/behave exactly as before (they use the
retained single-prefix overloads). Porting the action to 3.5/4.0 can follow up.

Testing

• Existing TestRewriteTablePath* suites pass (single-prefix path unchanged).
• New test: multiple prefix mappings relocate data + metadata + delete files.
• New test: overlapping prefixes resolve to the longest match.
• New test: a path matching no mapping fails with a clear error.
• New test: table with partition-statistics files is rewritten (no longer rejected).

[github-actions]

This pull request has been marked as stale due to 30 days of inactivity. It will be closed in 1 week if no further activity occurs. If you think that’s incorrect or this pull request requires a review, please simply write any comment. If closed, you can revive the PR at any time and @mention a reviewer or discuss it on the dev@iceberg.apache.org list. Thank you for your contributions.

[github-actions]

This pull request has been closed due to lack of activity. This is not a judgement on the merit of the PR in any way. It is just a way of keeping the PR queue manageable. If you think that is incorrect, or the pull request requires review, you can revive the PR at any time.

[krisnaru]

@anuragmantri can you help get eyes on this PR?

[anuragmantri]

I think this is a useful feature for users who have moved the data / metadata locations during the life of a table.

[github-actions]

This pull request has been marked as stale due to 30 days of inactivity. It will be closed in 1 week if no further activity occurs. If you think that’s incorrect or this pull request requires a review, please simply write any comment. If closed, you can revive the PR at any time and @mention a reviewer or discuss it on the dev@iceberg.apache.org list. Thank you for your contributions.

[github-actions]

This pull request has been marked as stale due to 30 days of inactivity. It will be closed in 1 week if no further activity occurs. If you think that’s incorrect or this pull request requires a review, please simply write any comment. If closed, you can revive the PR at any time and @mention a reviewer or discuss it on the dev@iceberg.apache.org list. Thank you for your contributions.

[uros-b]

cc @krisnaru regarding #17521 (review)