refactor/feat: 'Next' and 'Queued' segment API

[ianshade]

This PR is being opened on behalf of TV 2 Norge.

• What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
  Refactor that includes an addition and a change to the internal UserAction API, and to an endpoint of the HTTP API introduced in this release (release50), therefore not considered breaking.

• What is the current behavior? (You can also link to an open issue here)
  The currently existing setNextSegment action makes it possible to queue a segment, so that its first part will be set as Next when reaching the end of the current segment. There's no endpoint or UserAction available to set the first part of a given segment as Next.

• What is the new behavior (if this is a feature change)?

  • setNextSegment UserAction and the corresponding /playlists/{playlistId}/set-next-segment endpoint set the first playable part of the given segment as Next. - This corresponds to what has been known in the GUI as Set segment as Next.
  • queueNextSegment UserAction and the corresponding /playlists/{playlistId}/queue-next-segment endpoint queue the given segment, so that its first part will be set as Next when reaching the end of the current segment. However, if the next part is already outside of the current segment, the first playable part of the given segment will be set as Next. - This corresponds to what has been known in the GUI as Queue segment.

• Other information:
  The GUI has been updated to use the updated user actions. The nextSegmentId property of the Playlist has been renamed to queuedSegmentId for consistency.

Status

• Code documentation for the relevant parts in the code have been added/updated by the PR author
• The functionality has been tested by the PR author
• Automated tests to cover the new functionality and/or guard against regressions have been added
• The functionality has been tested by NRK

[codecov]

Codecov Report

Attention: 72 lines in your changes are missing coverage. Please review.

Comparison is base (685ddb6) 58.06% compared to head (f79a6a5) 58.10%.
Report is 53 commits behind head on release50.

Additional details and impacted files

@@              Coverage Diff              @@
##           release50    #1048      +/-   ##
=============================================
+ Coverage      58.06%   58.10%   +0.03%     
=============================================
  Files            479      479              
  Lines          78378    78647     +269     
  Branches        4093     4120      +27     
=============================================
+ Hits           45510    45696     +186     
- Misses         32808    32892      +84     
+ Partials          60       59       -1     

Files	Coverage Δ
meteor/lib/api/userActions.ts	100.00% <100.00%> (ø)
meteor/lib/userAction.ts	100.00% <100.00%> (ø)
meteor/server/api/userActions.ts	95.82% <100.00%> (+0.07%)	⬆️
packages/corelib/src/dataModel/RundownPlaylist.ts	100.00% <100.00%> (ø)
...es/job-worker/src/playout/activePlaylistActions.ts	94.33% <100.00%> (ø)
packages/job-worker/src/playout/lib.ts	70.30% <100.00%> (ø)
packages/job-worker/src/playout/lookahead/util.ts	88.88% <100.00%> (ø)
packages/job-worker/src/playout/selectNextPart.ts	99.34% <100.00%> (+0.01%)	⬆️
packages/job-worker/src/playout/setNextJobs.ts	100.00% <100.00%> (ø)
...ges/job-worker/src/playout/timings/partPlayback.ts	100.00% <100.00%> (ø)
... and 6 more

... and 11 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ianshade]

Note: The author of the original stable API PR has been consulted and they approve of this change.