chore: Use FDv1 DataSystem in the ldclient

[jsonbailey]

Note

Adopt FDv1 data system in client

• Replace LDClient’s direct data source/store wiring with Impl::DataSystem::FDv1; FDv1 wraps the original feature_store once (avoids nested wrappers), injects data_source_update_sink, exposes store, flag_change_broadcaster, and status providers, and cleans up via stop (including store_wrapper.stop).
• Delegate data_store_status_provider and data_source_status_provider from LDClient to the data system; add flush delegator to the event processor; refine SDK key nil validation for offline/LDD/custom sources.
• Update readiness and data access: initialized? now compares data_availability vs target_availability; all reads switched to data_system.store in evaluations and all_flags_state.
• Default data source creation moved into FDv1 (streaming by default; logs when disabling streaming and using polling).

Tests

• New spec/impl/data_system/fdv1_spec.rb covering store wrapping (no nested wrappers), processor selection (streaming/polling/offline/LDD), custom data source factory/instance handling, start/stop idempotency, availability semantics, diagnostic accumulator integration, and provider/broadcaster access.

^{Written by Cursor Bugbot for commit 59ae3c0. This will update automatically on new commits. Configure here.}

[jsonbailey]

The file used a mix of per method private and all methods after the declaration on line 717 of the original file. Moving to defining per method.

[keelerm84]

Are we sure these lines are equivalent given our previous discussions about this? I can't remember exactly where we landed on that.

[jsonbailey]

They should be equivalent for FDv1. This will need to be altered a bit when we introduce FDv2.

• Offline returns and expects DEFAULTS ✅
• Use_Ldd returns and expects REFRESHED (because it uses null processor) ✅
• If the data_source.Initialized is true the data_system returns REFRESHED and CACHED if false, but we expect REFRESHED✅