Historical Telemetry Provider needs to accept incoming "order" options for requests

[jvigliotta]

Summary

Currently telemetry request orders are hardcoded to asc this can lead to situations where the wrong set of limited telemetry is requested. We need to accept incoming order options from views making requests.

Expected vs Current Behavior

We should apply requests based on what views send in. We are hard coding to ascending.

Impact Check List

• [x] Data loss or misrepresented data?
• [ ] Regression? Did this used to work or has it always been broken?
• [x] Is there a workaround available? (not using limited mode)
• [x] Does this impact a critical component?
• [ ] Is this just a visual bug with no functional impact?

Steps to Reproduce

1. Navigate to a telemetry table that has telemetry
2. Ensure it is in limited mode (toggle at bottom right of telemetry table)
3. Set time conductor to a large range (1 hr or more)
4. Hover mouse over pause button
5. Refresh the browser
6. Pause as soon as telemetry request is finished (pretty much when pause button becomes visible)
7. Observe the timestamps for the data is from the beginning of the time range, not the end

Environment

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

Additional Information

Directly related to: https://github.com/nasa/openmct/issues/7636

[jvigliotta]

Testing

• Follow the repro steps, make sure that the results that come in do not have a large gap
• make sure the request that goes out has order=desc url param

[ozyx]

Verified Fixed-- Testathon 4/4/24

[davetsay]

verified