[Uptime] Fix timespan referencing to same values (#56601)

[shahzad31]

Summary

Fixes Timespan using same object for tsStart and tsEnd in Monitor List API !!

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

• This was checked for cross-browser compatibility, including a check against IE11
• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• This was checked for keyboard-only and screenreader accessibility

For maintainers

• This was checked for breaking API changes and was labeled appropriately
• This includes a feature addition or change that requires a release note and was labeled appropriately

[elasticmachine]

Pinging @elastic/uptime (Team:uptime)

[justinkambic]

What's the end result to the behavior of the application? This seems like a bug that CI should have caught before it was merged, if I'm understanding the code change correctly.

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 8c692e8

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[shahzad31]

What's the end result to the behavior of the application? This seems like a bug that CI should have caught before it was merged, if I'm understanding the code change correctly.

So because of using the same object, it was subtracting 5 minutes from both dates, hence setting timespan to 5 minutes in the past, because of that we are getting results which are always 5 minutes ago.

@justinkambic Well it's related to that timespan andrew increased and relative time handling i did.

So CI won't be able to catch it since it just increases or reduces timespan.

[shahzad31]

@andrewvc can probably add more why this wasn't go caught in CI, or how can we improve the tests for it.

[andrewvc]

The reason this was missed, most likely, is that we do a time intersection. So, the bug here resulted in a zero length point which still intersected the most recent checks (most likely).

What we need to add is a test that checks that we still match data that's somewhat stale. So, in other words do the query on a dataset that has data with timespans ending say a minute ago.

I'm OK with merging this as-is given where we are in the FF with manual testing, but we'll need to add a CI test here as well.

[andrewvc]

For the CI test, to be clear, I'm OK adding it after merging this PR.

[andrewvc]

LGTM, tested locally on this branch and master by setting a time range of last '15s'. This breaks without this patch.