Use restore Keeper retries for restored parts

[pamarcos]

RESTORE of replicated tables restores data by attaching parts through the same
sink path used by inserts. That path used insert_keeper_max_retries, so a
temporary Keeper outage or replica read-only period could fail a long-running
restore even when backup_restore_keeper_max_retries was configured to tolerate
it.

Pass the restore Keeper retry settings into restored part attachment, so the
data phase follows the same retry budget as the rest of RESTORE.

Changelog category (leave one):

• Bug Fix (user-visible misbehavior in an official stable release)

Changelog entry (a user-readable short description of the changes that goes into CHANGELOG.md):

Fixed RESTORE of replicated MergeTree tables so restored part attachment uses backup_restore_keeper_max_retries instead of the regular insert Keeper retry budget.

Documentation entry for user-facing changes

• Documentation is written (mandatory for new features)

[clickhouse-gh]

Workflow [PR], commit [7d6b959]

Summary: ✅

---

AI Review

Summary

This PR routes restored-part attachment in replicated MergeTree restore flows through backup_restore_keeper_* retry settings by threading ZooKeeperRetriesInfo from RestorerFromBackup into ReplicatedMergeTreeSink. The implementation is coherent across touched call sites, and the new stateless test exercises both the failing (backup_restore_keeper_max_retries = 0) and succeeding (backup_restore_keeper_max_retries = 1) paths with a targeted failpoint.

Final Verdict

• Status: ✅ Approve

[clickhouse-gh]

LLVM Coverage Report

Metric	Baseline	Current	Δ
Lines	84.10%	84.10%	+0.00%
Functions	91.10%	91.10%	+0.00%
Branches	76.50%	76.60%	+0.10%

Changed lines: 100.00% (61/61) | lost baseline coverage: 17 line(s) · Uncovered code

Full report · Diff report