Fix incorrect ATP time-range assertions

[albertoramosmonagas]

Problem description
While running tests, we detected a bug in some ATP scenarios. The problem is that steps such as:

• And the response property "$.timedPredictive..[*].startTime" is equal to or later than request body property "$.startDate"
• And the response property "$.timedPredictive...[*].endTime" is equal to or earlier than request body property "$.endDate" are incorrect.

According to the API specification, the returned intervals are expected to fully cover the requested time range. This means that:

• the first returned interval may start earlier than the requested start time, and
• the last returned interval may end later than the requested end time.

So the current ATP validation logic is too strict and does not reflect the intended API behavior. The implementation is correct; the issue is in the ATP step wording and validation rule.

Expected action
Update the ATP steps in CAMARA so they validate that the returned intervals fully cover the requested time range, instead of enforcing each interval boundary to stay within the requested boundaries.

Proposed replacement step:

• And the response property "$.timedPredictiveConnectivityData" intervals fully cover the requested time range from "$.startTime" to "$.endTime"

Additional context
Relevant specification excerpt:

Time ranges along for the cells within it. The request startTime or the request endTime have to be fully covered by the intervals. For example, if the intervals are 1-hour long and the input date range were [2024-01-03T11:25:00Z to 2024-01-03T12:45:00Z] it would contain 2 intervals (Interval from 2024-01-03T11:00:00Z to 2024-01-03T12:00:00Z and interval from 2024-01-03T12:00:00Z to 2024-01-03T13:00:00Z).