feat: Emit provider events from LaunchDarkly client status

[kinyoklion]

Forwards LaunchDarkly client status and flag change notifications to the OpenFeature SDK as provider events.

• The provider now includes OpenFeature::SDK::Provider::EventEmitter and registers listeners on the LaunchDarkly data source status provider and flag tracker.
• VALID emits PROVIDER_READY, INTERRUPTED emits PROVIDER_STALE, and OFF emits PROVIDER_ERROR with the GENERAL error code and the last error in the message.
• OFF deliberately does not use PROVIDER_FATAL: the LaunchDarkly client can still evaluate its last known flag data, and a fatal state would make the OpenFeature SDK return call-site defaults instead.
• Flag changes emit PROVIDER_CONFIGURATION_CHANGED with the changed flag key.

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

Part of an audit of the LaunchDarkly OpenFeature providers against the current OpenFeature specification. Provider events (spec section 5) were not implemented here, so applications had no way to react to LaunchDarkly connection loss, recovery, or flag configuration changes through the OpenFeature API.

Describe the solution you've provided

Two small listener classes in Impl translate LaunchDarkly notifications into OpenFeature events, and the provider registers them when the client is constructed. EventEmitter#emit_event is a no-op until the OpenFeature SDK attaches its configuration to the provider, so events raised before the provider is set are safely dropped.

Describe alternatives you've considered

Mapping OFF to PROVIDER_FATAL — rejected for the reason above; this matches the Java provider and the corresponding fix being made in the Python provider. Emitting one event per changed flag with no payload — rejected in favor of including flags_changed so handlers can filter.

Testing

bundle exec rake (RSpec + RuboCop) on Ruby 3.4: 59 examples, 0 failures; 15 files inspected, no offenses. Ruby 3.4 was used because the gemspec requires >= 3.4.

@cursor review

Link to Devin session: https://app.devin.ai/sessions/0c452d209ec54b068ba120b4c92b8f6c
Requested by: @kinyoklion

---

Note

Overview
Implements OpenFeature provider events (spec section 5) so apps can react to LaunchDarkly connection state and flag updates through the OpenFeature API.

The Provider now includes OpenFeature::SDK::Provider::EventEmitter and registers two listeners when the LD client is constructed: on data_source_status_provider and flag_tracker.

Data source status maps to events: VALID → PROVIDER_READY, INTERRUPTED → PROVIDER_STALE (with message), OFF → PROVIDER_ERROR with GENERAL and last error details in the message—not PROVIDER_FATAL, so evaluation can still use last-known flags. INITIALIZING emits nothing.

Flag changes emit PROVIDER_CONFIGURATION_CHANGED with flags_changed containing the changed key.

New Impl::DataSourceStatusListener and Impl::FlagChangeListener translate LD notifications into emit_event calls; specs cover each mapping.

^{Reviewed by Cursor Bugbot for commit dc2ae67. Bugbot is set up for automated code reviews on this repo. Configure here.}

[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

[kinyoklion]

aside: We don't say fatal, because then OF short-circuits evaluations.