Staleness should be reported for `really` stale telemetry (timestamp before start bound)

[davetsay]

Summary

Latest available data which is stale, is not being marked as stale, unless it arrives within the specified time conductor bounds. Actually, it is marked stale if it arrives after the start bounds, which is another bug since it should not be stale if it is future telemetry. Latest available telemetry could be stale but have been received long before the start bound, in which case it should remain marked as stale until new telemetry datum comes in.

This can occur in infrequently updated telemetry such as positional or state telemetry.

(This is based on the assumption that a staleness provider is marking telemetry as stale if its timestamp is greater than some tolerance).

Expected vs Current Behavior

• Latest available telemetry should be marked stale, even if the timestamp is prior to the start bound
• Any incoming telemetry, including latest available telemetry, should not be marked as stale if the timestamp is after the end bound

Steps to Reproduce

1. Open a display with stale telemetry (should be as sparse as possible)
2. Reduce the start time of the time conductor so that the start time is after the timestamp of the latest telemetry datum
3. Navigate away and back to telemetry
4. Observe telemetry is not marked as stale
5. Return the start time of the time conductor so that the start time is before the timestamp of the latest telemetry datum
6. Navigate away and back to telemetry
7. Observe telemetry is again marked as stale
   The same telemetry is marked or not marked as stale depending on the start bound, but it should be marked as stale in both cases.
8. Repeat Steps to Reproduce but with toggling the latest available telemetry timestamp before and after end bounds

Environment

• Open MCT Version: 3491473
• Deployment Type: VIPER
• OS:
• Browser:

Impact Check List

• Data loss or misrepresented data?
• Regression? Did this used to work or has it always been broken?
• Is there a workaround available?
• Does this impact a critical component?
• Is this just a visual bug with no functional impact?
• Does this block the execution of e2e tests?
• Does this have an impact on Performance?

Additional Information