Stitcher live stream support

[matvp91]

Stitcher is an open playlist manipulator and does not exclusively work with HLS playlists generated by Superstreamer. While it initially started as a way to solely manipulate our own playlists, we've moved away from this thought and added support for external playlists in 8db7e1c.

The next logical step is to no longer limit Stitcher to handle playlists solely with an ending EXT-X-ENDLIST tag, but allow it to insert interstitials for live streams too. Top of my head, there's a few issues to tackle first:

• Make parser work with multiple tags, not solely an EXTINF followed by a literal. Live streams have possibly EXT-X-PROGRAM-DATETIME tags in between or before (there's no fixed order). Ideally, we'd have our parser know that the lexical tag it encounters belongs to a segment, and groups all subsequent tags up until it finds the literal. This should make it sufficiënt to proxy live streams through Stitcher.

• Let's focus on adding a preroll, I'm not sure yet how to do this when the window is sliding future wise. When there's an EXT-X-ENDLIST, it's rather easy as each interstitial is relative to the start of the asset. With live, there's no zero based approach. We'd be starting at max. 3 times the target duration from live edge instead. Although I'm not sure that's a given, it feels like guessing where a DATE-RANGE should be isn't the right approach. Bottom line, I have no idea how to approach the technical aspect of scheduling interstitials in a playlist that's EXT-X-PLAYLIST-TYPE:LIVE.

While we're touching the parser again, there's a few other things to take care of:

• EXT-X-MAP is now mapped once and copied in each segment (this came from the idea that there's only a single init segment). This should be mapped to a single segment. We should change this in both parse and stringify. Atleast we'd be more in line with what the HLS spec describes.
• Tests, tests, tests, the stitcher is growing rapidly and when we atleast start with building something live related, we should make sure we have proper tests in place as we wouldn't want to break VOD functionality.

Revision 1

• Scheduling an interstitial to play before live content can be done by specifying CUE=PRE,ONCE (see https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis-16#section-4.4.5.1).
• When we have an ad scheduled, lets make sure to expose the ad structure in the ASSET-LIST so that clients can pick up which impressions to fire on the client (see https://www.svta.org/project/ad-creative-signaling-in-dash-and-hls/)
  • Build a small library that can be bound to facade, that fires the impressions.

The asset-list.json endpoint requires a "lookupDate" in the query string. We should drop this param as it is relative to the start of a session (which for VOD is session.startTime), this logic is not transferable to live streaming (where we do not explicitly set EXT-X-PROGRAM-DATETIME but rely on the PDT that is present in the original playlist that Stitcher proxies). The idea is to migrate this to a generic "lookupId" (in short, just "id" would work) which can be the relative timeOffset (eg; the zero based time from the VMAP or when we specify timeOffset), and we'll use that id to lookup the items that need to be served in the ASSETS response.

Revision 2

See 1819cdc

There's a few TODO's though, and I'm merely spinning up ideas here.

• An AdBreak in a VMAP can be repeated with the same timeOffset but contain a different vastData / vastUrl property.
• There's some cleaning up to do in terms of code, data structures and where we'd put types. Especially now since we no longer have a harsh split between VMAP / VAST and manual interstitials logic (one gets resolved to the other until an interstitials list is available).