fix: Wait for the data source when no start wait time is configured

[kinyoklion]

Initialization no longer fails immediately when the provider is constructed with a wait time of zero.

• A wait time of zero tells the LaunchDarkly client constructor not to block, so init ran while the data source was still INITIALIZING and reported a failed initialization even though the connection was about to succeed.
• init now waits for the data source to become valid or to fail permanently when the wait time is zero, and keeps its existing behavior for a positive wait time, which the client constructor has already applied.
• The Python provider already behaves this way; this brings the Ruby provider in line with it and with the initialization requirements of the OpenFeature provider behavior spec.

Found during the weekly OpenFeature provider audit.

Implementation details

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.

Describe the solution you've provided

The provider keeps the wait time it was constructed with. When it is zero, 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 are the states which 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.

Describe alternatives you've considered

Applying a default timeout when the wait time is zero: zero is the caller asking for no deadline, and the OpenFeature SDK is what 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 (79 examples) and bundle exec rubocop on Ruby 3.4.5. The new tests cover a zero wait time succeeding once the data source becomes valid, a zero wait time waiting for an outcome which arrives after init is called, a positive wait time not waiting a second time, and the outcome listener's per-state behavior.

The README's Initialization row describes the zero wait time behavior.

Link to Devin session: https://app.devin.ai/sessions/fe1eb757fe694ef79f3d09f6307d4b47
Open in Devin Desktop: https://app.devin.ai/desktop/session/fe1eb757fe694ef79f3d09f6307d4b47?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