JAVA-5950 Update Transactions Convenient API with exponential backoff on retries

[nhachicha]

JAVA-5950

[Copilot]

Pull request overview

This PR implements exponential backoff with jitter for transaction retries in the MongoDB Java driver's convenient transaction API (withTransaction). The implementation follows the specification with a growth factor of 1.5, base delay of 5ms, and maximum delay of 500ms.

Key Changes:

• Added ExponentialBackoff utility class to calculate retry delays using exponential backoff with random jitter
• Modified ClientSessionImpl.withTransaction() to apply exponential backoff before each transaction retry attempt
• Enhanced timeout handling to check limits before applying backoff delays

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
driver-core/src/main/com/mongodb/internal/ExponentialBackoff.java	New utility class implementing exponential backoff algorithm with factory methods for transaction and command retries
driver-core/src/test/unit/com/mongodb/internal/ExponentialBackoffTest.java	Comprehensive unit tests verifying backoff calculations, jitter application, and max delay capping
driver-sync/src/main/com/mongodb/client/internal/ClientSessionImpl.java	Integration of exponential backoff into transaction retry logic with timeout checks
driver-sync/src/test/functional/com/mongodb/client/WithTransactionProseTest.java	Functional test validating exponential backoff behavior with simulated transient errors

Comments suppressed due to low confidence (1)

driver-core/src/main/com/mongodb/internal/ExponentialBackoff.java:1

• The commented-out wouldExceedTimeLimit() method and its associated tests should be removed if they are not being used. Keeping dead code reduces code maintainability and can confuse future developers about the intended design.

/*

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The assertion threshold of 5ms is extremely fragile and may cause test flakiness on slow or heavily loaded CI systems. The test could fail even when backoff is working correctly due to timing variations. Consider either removing this timing assertion entirely (since the retry count assertion already validates the behavior) or using a more lenient threshold with a clear comment explaining the expected minimum delay calculation.

Suggested change

	assertTrue(elapsedTime > 5, "Expected backoff delays to be applied");
	// Timing assertion removed to avoid test flakiness on slow CI systems.

[Copilot]

[nitpick] Extra blank line creates inconsistent spacing. Remove the blank line at 272 for consistent code formatting.

Suggested change