[jsonbailey]

Summary

Stacked on the identify docs PR. The FDv1 streaming data source no longer stops for good after an HTTP error such as a 401.

• The SDK owns the reconnect delay. It makes the SSE client with autoReconnect: false, closes it on any failure, and reconnects after the RetryState delay: 1 second up to 30 seconds normally, and 5 minutes up to 1 hour after an unexpected failure. The backoff resets after 60 seconds of healthy streaming.
• Logs use warn for normal failures and error for unexpected ones, state the real delay, and add a credential hint only for 401 and 403.
• A restart for a connection that has already been replaced is ignored, so a late invalid message cannot close a newer, healthy connection.
• FDv2 streaming maps the new SSE errors to interrupted, as Android FDv2 does, and logs the failure kind.
• A cached identify no longer reports an unhandled error when the first stream attempt fails.
• Contract test service: declares retry-conformance-fdv1-streaming.
• common_client needs the released launchdarkly_event_source_client and launchdarkly_dart_common versions before this merges. The pin bumps follow those releases.

[jsonbailey]

Any message, including ping, starts the 60 s healthy measurement. iOS (#533) and Android (#406) do the same. The spec clarification is sdk-specs #276.

[jsonbailey]

iOS and Android handle stream messages synchronously on the stream's own thread, so they cannot hit this. Here, DataSourceManager handles events asynchronously, so a late invalidMessage could restart a newer connection. The generation token ignores a restart for a connection that has been replaced.

[jsonbailey]

Known follow-up: messages already queued from a restarted connection are still applied until the next full put. iOS does the same. Android drops them, because it restarts after the current message. Tracked separately.