On-call schedule timeline view - should be aligned with shifts rather than days

When implementing the rotation interval restrictions for the weekly timeline view, I realised that it won't work under the current scheme where we align the visual blocks with days.

This scheme also causes another issue, whereby timezones don't show their offset. e.g. a rotation starting at midnight will look the same as a rotation starting at midday.

• 2 weeks view.
• 1 day view.

In addition, there's an issue with modifying shifts during the 1 day view: #324608 (comment 529854305).

Proposal

In the 2 weeks view, change the timeline blocks so that they align with the true start/end times for all rotations. This will match the current behavior for the 1 day view.

Implementation

The backend gives us for each rotation

• startsAt (a full ISODateString)
• endsAt (a full ISODateString)
• length and unit (hours/days/weeks)
• activePeriod (a start and end hour, given in the schedule timezone)

Based on the data that we get from the backend, this should be possible to do. But it would be a re-write of a significant percentage of the timeline display code.

This should occur before, or during the 'Consider using CSS Grid approach to the timeline' issue. If we do it after, we risk re-writing the same code. Given they have some overlap, it may make sense to work on them together. => This was not a valid option.

Merge train

The work will be merged in pieces, as part of the following merge train:

What	Merge
Introduce new helper for shift utils	!58202 (merged)
Update shift width query	!58204 (merged)
Consolidate Week and Day shift items	!58322 (merged)
Render grid as single timeline cell and update day indicator	!58342 (merged)
Remove old code	!58352 (merged)
Update / Add specs	!58436 (merged)
Replace inline JS with CSS media queries for rotation assignee	TBA

With !57300 (closed) acting as a sandbox/definition of done merge(this is what the result should look like if we never broke down the work into multiple merges).