feat: Playlist and part timings on live status gateway

[PeterC89]

• What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
  Feature

• What is the current behavior? (You can also link to an open issue here)
  Timings information isn't available in the live status gateway

• What is the new behavior (if this is a feature change)?
  Playlist and part timing is available in the live status gateway

• Other information:

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

All modified and coverable lines are covered by tests ✅

Comparison is base (cbc551a) 58.20% compared to head (cc70da5) 81.36%.
Report is 2 commits behind head on release51.

❗ Current head cc70da5 differs from pull request most recent head acdd13d. Consider uploading reports for the commit acdd13d to get more accurate results

Additional details and impacted files

@@              Coverage Diff               @@
##           release51    #1059       +/-   ##
==============================================
+ Coverage      58.20%   81.36%   +23.15%     
==============================================
  Files            507      142      -365     
  Lines          81414    27361    -54053     
  Branches        4279     2231     -2048     
==============================================
- Hits           47391    22262    -25129     
+ Misses         33965     5072    -28893     
+ Partials          58       27       -31     

Files	Coverage Δ
packages/job-worker/src/playout/adlibAction.ts	100.00% <100.00%> (ø)

... and 438 files with indirect coverage changes

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

[PeterC89]

I've just realised that #1053 covers some of this already, if that PR gets accepted I'll tweak this one to just do playlist timing and metadata.
Will also update the schema as I'd completely forgotten to do that...

[jstarpl]

I'm wondering, what's the specific use case for exposing the PartInstance metadata to the API consumers? I think so far we've seen the Metadata property as a private datastore owned by the blueprints. One option we were looking at was a namespaced public datastore that could be consumed by various consumers and potentially cross-compatible between blueprints (via some yet-to-be-defined extension proposal process?). Or maybe this is data that could be otherwise compiled somehow already, just that it's difficult and we need to expand some feature area?

[PeterC89]

I'm wondering, what's the specific use case for exposing the PartInstance metadata to the API consumers? I think so far we've seen the Metadata property as a private datastore owned by the blueprints. One option we were looking at was a namespaced public datastore that could be consumed by various consumers and potentially cross-compatible between blueprints (via some yet-to-be-defined extension proposal process?). Or maybe this is data that could be otherwise compiled somehow already, just that it's difficult and we need to expand some feature area?

A simple example would be a countdown system with audible counts which require different counting styles / voices depending on the type of item being counted.
Whilst you could tell the system about all the layers it feels like it would be easier to have a known metadata property that dictates this, especially as that means that adding layers doesn't require the external system to be told about something new.

[Julusian]

Does it have to be the same metaData field that already exists, or should this be fed from a new metaData field?
My concern with exposing this metaData field is that at NRK, we put the blob of almost raw MOS into this field, as well as some additional properties derived from the generation of the part. I don't see a situation where all of this data would be useful externally, but I can see that perhaps a subset of it will be

We should probably rename these fields to blueprintsMetaData to clarify this intention better, I don't know what this new field should be called.

[PeterC89]

Does it have to be the same metaData field that already exists, or should this be fed from a new metaData field? My concern with exposing this metaData field is that at NRK, we put the blob of almost raw MOS into this field, as well as some additional properties derived from the generation of the part. I don't see a situation where all of this data would be useful externally, but I can see that perhaps a subset of it will be

We should probably rename these fields to blueprintsMetaData to clarify this intention better, I don't know what this new field should be called.

That would work for me, we're not currently putting anything quite that significant into the metaData field, although I'd agree most of what's in there isn't much use externally.
But it would definitely be useful to have some sort of way of easily passing playlist / segment / part / piece metadata out through the live status gateway.