Accommodate editing on-call rotations in on-call shift persistence

What does this MR do?

Context

• ~"group::monitor" is currently building on-call schedule management. A Schedule has many Rotations, which in turn can have many Shifts for the Participants of the Rotation.
• Shifts are generated based on the attributes of the rotation (rotation length, start time, Participants etc). As Shifts are occurring, they are saved to the database as a historical record. This works by cronjob + worker which determines which shifts need to be saved based on what's already in the DB.
• Rotations can have 'active periods' where, within a day-based or week-based rotation, the participant is only on-call for certain times during the day.

To poke around what's been built so far, check out https://staging.gitlab.com/gitlab-org/monitor/monitor-sandbox/-/oncall_schedules.

To poke around locally, enable the oncall_schedules_mvc feature flag.

Some screeshots of what's there, just to give an idea:

Schedule view	Rotation attributes

Scope of this MR

This MR contributes a small piece of the logic needed to edit <code data-sourcepos="19:65-19:73">Rotations</code>. Edits will work by cutting off any existing shifts and generating new shifts based on the new attributes of a Rotation, as though the previous attributes had never existed.

This MR is one of several towards this goal:

• Avoid backfilling shifts which did not happen after edits - this MR
• Service to edit rotation attributes and participants
• Service to update the current shift based on modified rotation
• GraphQL for editing rotations - TBD

The change in this MR ensures that any on-call shifts saved to the database are indeed shifts that have actually occurred or are currently occurring. After a rotation is edited, we no longer have access to the old attributes and can no longer make assumptions about what would have occurred. We can only know which shifts have occurred starting after the edit.

The actual code change is minor, so this MR mostly adds tests which assert that we don't want to backfill shifts which did not happen.

This is not user-facing, so no changelog is included.

Does this MR meet the acceptance criteria?

Conformity

• [-] Changelog entry
• [-] Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• [-] Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers
• Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team

Related to #262862