discussion: align CommitNumRetriesDefault with Java/PyIceberg (0 → 4)?

[laskoviymishka]

Parent: #830

Open question, not a blocker. iceberg-go's CommitNumRetriesDefault was set to 0 in PR #912 because the retry loop without refresh-and-replay was harmful (re-issued the same stale conflict). PR #945 added refresh-and-replay, so the original reason for the 0 default is gone — but the constant has not been flipped.

Java and PyIceberg both default to 4 retries. A user porting from either of those clients sees fail-fast on the first conflict today and has to dig into properties to figure out why. The fix is a one-line constant change plus a sweep of tests that assume the no-retry path.

Reasons to flip:

• Java parity / out-of-box experience.
• The retry mechanism is fully wired and exercised in CI.
• Existing users who want fail-fast can set commit.retry.num-retries=0 explicitly.

Reasons to hold off:

• Existing users (since feat(table): retry doCommit on commit-conflict errors (#830) #912 in April) have been running with default 0. Flipping silently changes their commit-latency profile under contention — a 4-attempt exponential-backoff loop can add seconds before a terminal error surfaces.
• Some retry tests calibrated for 0 would need adjustment.

Filing as a question, not a feature, because the answer is a defaults-tuning judgment call rather than a missing capability. Looking for input from maintainers on whether the parity argument outweighs the silent-behavior-change concern, and ideally a release note if we do flip.