Configuration Source Extraction part 3/5 - Add Configuration HTTP Client Interface

[typotter]

Configuration Source Extraction part 3/5 - Add Configuration HTTP Client Interface

🥞 Configuration Refactor Stacked Pull Requests 🥞

🔲 Make HTTP client injectable via constructor (#207)
🔲 Integrate default HTTP client implementation (#206)
👉 Add configuration HTTP client interface (this PR)
✅ Add flagsSnapshotId field to Configuration (#208)
✅ Extract DTO interfaces for downstream SDK extensibility (#197)
⬇️ feature/v4 (trunk)

Motivation and Context

Building on the DTO interface extraction (#197) and the flagsSnapshotId field addition (#208), we need to provide an interface for configuration fetching that allows downstream SDKs to:

1. Use platform-specific HTTP clients and deserialization: Android's HttpUrlConnection, Ktor, custom networking libraries
2. Manage their own connection pooling: Control thread pools, connection limits, timeouts
3. Implement custom retry logic: Exponential backoff, circuit breakers, custom error handling
4. Add platform-specific features: Certificate pinning, custom SSL contexts, proxy configuration
5. Avoid OkHttp dependency: Not all platforms want/need OkHttp bundled

The current tight coupling to EppoHttpClient (OkHttp-based) prevents this flexibility.

Description

Extract IEppoConfigurationHttpClient interface and supporting request/response classes to enable pluggable HTTP client implementations.

New Classes Added

1. IEppoConfigurationHttpClient - Interface for HTTP configuration fetching

   • Sync/async methods for flags and bandits
   • Returns generic ConfigurationResponse<T> wrapper

2. ConfigurationRequest - Request data class

   • URL, API key, SDK name/version, previous ETag

3. ConfigurationResponse<T> - Generic response wrapper

   • Payload (flags or bandits), ETag, status code, error message
   • Static factories: Flags.success(), Bandits.notModified(), etc.
   • Convenience methods: isSuccess(), isNotModified(), isError()

4. ConfigurationRequestFactory - Factory for creating requests

   • Encapsulates URL/API key configuration
   • Creates flag/bandit-specific requests

Tests Added

• ConfigurationRequestTest (4 tests) - Request creation and validation
• ConfigurationResponseTest (18 tests) - Response factory methods, status checks
• ConfigurationRequestFactoryTest (8 tests) - Request factory behavior

Total: 30 new tests ensuring robust API contracts.

How has this been documented?

• Comprehensive Javadoc on all classes and methods
• Clear API contracts in interface documentation
• Test coverage demonstrates usage patterns

How has this been tested?

• 30 new unit tests covering all new classes
• All existing tests pass (no functional changes yet - integration in next PR)

Breaking Changes

None. This PR only adds new classes without modifying existing behavior.

Dependencies

Depends on: PR #208 (typo/etag-in-configuration)
Blocks: PRs #206, #207

[typotter]

• Nullable param to be added to init and constructor for EppoClient
• Default implementation will use OkHttp & sdk-specific json parsing util.
• Implementations are responsible for network requests and parsing responses.

[typotter]

IFlagConfigResponse and IBanditParametersResponse are interfaces all the way down