fix: use TIME_FUDGE_FACTOR rather than rounding by decimal digits

[brandonocasey]

Description

Currently we ran into an issue with roundSignificantDigit because it is rounding integer whole numbers when it seems like it was only made to round floats. This can cause us to download multiple duplicate segments on slow connections. Instead I propose that we only round by TIME_FUDGE_FACTOR here. This will prevent us from having to do any rounding at all.

Why the current solution is bad:

Rounding a value of 2.111111 to 2.111112 is less than 1 milliseconds a very small change but rounding from 2.1 to 2.2 is 100ms. Both are possible with the current code.

New solution

All numbers are rounded up or down by 33 milliseconds

Possible Solutions:

1. Cap the rounding at TIME_FUDGE_FACTOR for all numbers, but round less for longer floats. Not sure this one really makes sense as longer floats are not necessarily more accurate.
2. Don't round for numbers less than 1 decimal digits, effectively caps rounding at 99ms, which is still very high.
3. Don't round for numbers less than 2 decimal digits, effectively caps rounding at 9ms, which might not be enough? It seems to have been working until now, or we didn't notice that it wasn't

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[gkatsev]

Since this is a bug fix and helps us request less segments, I think we can just bring it in.

[gesinger]

Looks good, but would be good to have a test showing the behavior.