Support configurable consecutive-failure threshold to improve resilience in flaky networks

[asyncawaited]

I’m using Connectivity v8.0.0 in an environment with spotty or weak network links. Today, a single failed HTTP probe instantly marks the connection as “disconnected,” which leads to frequent false positives (flapping) whenever there’s a transient hiccup.

I also noticed that even when you configure multiple endpoints in the connectivityURLs array, a momentary network glitch can cause all of them to fail simultaneously, immediately tripping the success threshold. That makes it impossible to tolerate any packet loss or latency spikes.

Expected Behavior:
• Allow the consumer to specify a “consecutive failure” tolerance (e.g. 3 consecutive failures) before reporting a real disconnect.
• Otherwise, transient packet loss, slow DNS resolution, or latency spikes should not immediately flip the connectivity state, even if all connectivityURLs happen to fail at once.

Actual Behavior:
• With the default configuration (one URL + 100% success threshold), ConnectivityPublisher reports .isConnected == false on the first timeout or error, even if the next probe would succeed.
• When multiple URLs are provided, any brief outage that affects the entire connectivityURLs list will also trigger an instant disconnect.

Suggested Enhancement:
Add a new property—perhaps failureThreshold or maxConsecutiveFailures—to the ConnectivityPublisher.Configuration (and/or polling APIs). When set, the library would buffer successive failures across polling rounds and only emit a disconnect event after that many consecutive errors. This would enable a “fast reconnect, slow disconnect” model and greatly improve usability in unstable networks.