In 3.0, the packet loss metric used to trigger connection status alerts was
changed to the one generated by the `startMonitoringNetwork` method used by the
connection status modal. Since packet loss thresholds were not adjusted (0.5,
0.1, 0.2), a single lost packet causes the status alert to be permanently
stuck on "critical". This is explained by how different those metrics
are:
- **Before (2.7):** A 5-probe wide calculation of inbound packet loss
fraction based on `packetsLost` and `packetsReceived` metrics.
- **Now (3.0):** An absolute counter of inbound lost packets.
This commit restores the previous packet loss metric used to trigger
connection status alerts, reverting to the original collection method via
`/utils/stats.js`. This resolves the issue, but further work is needed in
subsequent PRs:
- Unify the collection done in `/utils/stats.js` with the
`startMonitoringNetwork` method.
- Incorporate the remote-inbound `fractionsLost` metric to account for packet
loss on both legs of the network (in/out).
- Update the packet loss metric displayed in the connection status modal to
show a more meaningful value (e.g., packet loss percentage over a specific
probe interval). An absolute counter of lost packets isn't useful for end
users.
- Update the alert log to use the fraction or percentage above
