feat: Support waiting indefinitely for initialization

[kinyoklion]

A nil wait time now asks the provider to wait for the LaunchDarkly client without a deadline.

• wait_for_seconds: nil makes init wait until the data source becomes valid or fails permanently; the client constructor does not block.
• A wait time of zero keeps its duration meaning: nothing waits, and init reports a failed initialization unless the client is already ready.
• A positive wait time is unchanged; the client constructor applies it and init does not wait a second time.
• Follows the initialization requirements of the OpenFeature provider behavior spec, which requires a value distinct from any duration to request indefinite waiting. Matches the Python provider.

Found during the weekly OpenFeature provider audit. Updated from the earlier revision of this PR, which overloaded a zero wait time to mean "wait indefinitely".

Requirements

• I have added test coverage for new or changed functionality
• I have followed the repository's pull request submission guidelines
• I have validated my changes against all supported platform versions

Related issues

None.

Implementation details

The provider keeps the wait time it was constructed with and passes zero to the LaunchDarkly client constructor when it is nil, so construction never blocks in that case. When the wait time is nil, init subscribes a DataSourceOutcomeListener to the data source status provider, then checks whether the client is already initialized or the data source is already OFF before blocking on a queue, so an outcome reached between construction and subscription is not missed. The listener is removed once an outcome arrives. VALID and OFF decide the outcome; INITIALIZING and INTERRUPTED leave the client still trying, so they do not end the wait.

Whether initialization succeeded is still decided by initialized?, and a failure still raises, which the OpenFeature SDK turns into the ERROR state. A failed initialization is not terminal: status changes keep flowing, so a later VALID state reports the provider as ready.

Describe alternatives you've considered

Applying a default timeout for nil: nil is the caller asking for no deadline, and the OpenFeature SDK decides how long to wait for a provider.

Polling initialized?: the data source status provider already reports transitions, so polling would only add latency and wake-ups.

Additional context

Testing: bundle exec rspec (80 examples) and bundle exec rubocop on Ruby 3.4.5. Tests cover an indefinite wait succeeding once the data source becomes valid, an indefinite wait for an outcome arriving after init is called, a zero wait time not waiting at all, a positive wait time not waiting a second time, and the outcome listener's per-state behavior.

The README's Initialization row describes the nil behavior.

Link to Devin session: https://app.devin.ai/sessions/1fd3fcbfe79f482e8b58be29e8df2ffb
Open in Devin Desktop: https://app.devin.ai/desktop/session/1fd3fcbfe79f482e8b58be29e8df2ffb?variant=devin
Requested by: @kinyoklion

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[devin-ai-integration]

@cursor review

[devin-ai-integration]

@cursor review