chore: Add support for FDv1 polling synchronizer

[keelerm84]

Note

Introduces an FDv1 polling fallback and triggers automatic failover from FDv2 based on response headers, with config hooks, parsing, and tests.

• Data acquisition / failover:
  • Streaming and polling now detect X-LD-FD-Fallback: true and emit updates with revert_to_fdv1, causing immediate switch to FDv1.
  • FDv2 consumes revert_to_fdv1 to switch synchronizers; OFF without fallback no longer implies FDv1.
• Polling (FDv2 + FDv1):
  • Add Urllib3FDv1PollingRequester using LATEST_ALL_URI.
  • Implement fdv1_polling_payload_to_changeset for FDv1 flags/segments full-transfer parsing.
  • Include headers in UnsuccessfulResponseException usage; propagate X-LD-EnvID and fallback flags.
• Streaming:
  • Handle Start action headers; on fallback header emit OFF + revert_to_fdv1.
  • Improved error handling with recoverability and header-aware fallback.
• Config:
  • DataSystemConfig gains fdv1_fallback_synchronizer.
  • Add ConfigBuilder.fdv1_compatible_synchronizer(...) and wire into default(), streaming(), and polling() (uses FDv1 polling requester).
• Store:
  • Reorder persistence and change-event emission to persist first, then notify; same for delta updates.
• Util:
  • UnsuccessfulResponseException now carries headers; throw_if_unsuccessful_response passes them.
• Tests:
  • Add comprehensive FDv1 payload parsing tests and FDv2 fallback behavior tests; persistence tests adjusted.
• Dependencies:
  • Bump launchdarkly-eventsource to >=1.5.0,<2.0.0.

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

[kinyoklion]

Is there any way, when changing data sources, that this etag could be a problem for us?

[kinyoklion]

Like the our payload in the store doesn't have to correspond to the to this etag if there was some data source in the interim. But I think that would be, at worse, a delay and it would require some inconsistent back-end state.

[keelerm84]

When we switch over to the polling mode, the etag is empty, ensuring the first request is going to get the full payload. The header from then is only used within the context of this class, I don't think that's problematic. Additionally, when you fallback to FDv1, you don't recover from that. This only happens if FD triggers the fallback, and that's only if something is pretty wrong.