chore: Add persistence store support for FDv2

[keelerm84]

Note

Adds persistent data store (read-only/read-write) support to FDv2 with status monitoring, configuration hooks, and comprehensive tests.

• FDv2 / Data System:
  • Integrates optional persistent FeatureStore with read-only/read-write modes via FeatureStoreClientWrapper; wires DataStoreStatusProvider and availability monitoring; exposes data_store_status_provider.
  • Improves logging (replace prints with log).
• Config / Builder:
  • Extends DataSystemConfig with data_store_mode and data_store; primary_synchronizer now optional.
  • ConfigBuilder adds data_store(...), relaxes build rule (secondary requires primary), and provides daemon(...) and persistent_store(...) helpers.
• Status & Interfaces:
  • Adds DataStoreMode enum; implements DataStoreStatusProviderImpl and DataStoreStatus.__eq__.
  • DataStoreStatusProvider.is_monitoring_enabled() support and propagation from stores.
• Store:
  • Dual-mode in-memory/persistent behavior; persists full and delta updates when writable; adds error logging.
• Tests:
  • Adds extensive persistence and status tests (test_fdv2_persistence.py) and updates config builder tests.

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

[cursor]

Bug: Deadlock Risk in FeatureStoreClientWrapper

In FeatureStoreClientWrapper.__update_availability, the lock acquired before self.__poller.start() isn't released if start() raises an exception. This missing try/finally block can lead to a deadlock, contrasting with other lock usages in the method.

Additional Locations (1)

• ldclient/impl/datasystem/fdv2.py#L102-L106

 

[kinyoklion]

What is the threading situation like for this dispatch? Is the caller thread always the same thread?

[kinyoklion]

Is there a reason this has to use lock/unlock vs with?