VTT cues are never cleaned up. Fix memory leak in live.

[JordanPawlett]

This PR will...

Implement flushing of the TextTrackCueList in accordance with the liveBackBufferLength config option, for live mode only.
This means that the id3 cues relevant to the current live buffer will still be maintained. However, we avoid the continuous growth that eventually consumes all the memory.

Why is this Pull Request needed?

VTT cues are not cleaned up until a stream is destroyed.
Long Live streams lead to a memory leak, as the TextTrackList continues growing with Cues until the browser runs out of memory and becomes un-responsive.

Are there any points in the code the reviewer needs to double check?

Resolves issues:

Checklist

• changes have been done against master branch, and PR does not conflict
• new unit / functional tests have been added (whenever applicable)
• API or design changes are documented in API.md

[OrenMe]

In general this kind of logic should reside in the ID3 controller as it is the one that manages the ID3 track, and you can see this by the fact that you had to reference the controller through the coreComponents in a way which is non safe, as no one guarantees it will retain its index (7) in anyway.
I also think it is a bit "confusing" that we have a buffer-controller but it handles only AV buffer and not all kinds of buffer, although I do believe the only other buffer we have is for text tracks(captions, subtitles and ID3), but the use cases for handling are so different that there's no point for mixing them probably.

[JordanPawlett]

I left the coreComponents index (7) lookup in purposefully to try exaggerate where i needed a point in the right direction.
Agreed that the logic is better residing in the id3-controller (as mentioned in my pr). However, there's no concept of a buffer in there - I feel it makes sense to tie the flushing of the VTT cues with the live buffer, as you would avoid seeking into the flushed section anyway. Any suggestions?

[JordanPawlett]

Had a chance to look at how hls is communicating with events.
I've moved the logic into the id3-controller.
An LIVE_BACK_BUFFER_REACHED Event is now being fired once the liveBackBufferLength option is exceeded. This is triggering the VTT cue flush, to be inline with the live buffer flush.

[JordanPawlett]

It seems like the tests on master are currently breaking.

[michaelcunningham19]

I tested this out on a live stream w/ many ID3 cues that I have access to, comparing against this branch and current master. Both were using liveBackBufferLength of 120

I verified that the ID3 cues are being removed properly 👍

Thoughts on getting this in soon, @johnBartos, @itsjamie, @OrenMe ?

[JordanPawlett]

I tested this out on a live stream w/ many ID3 cues that I have access to, comparing against this branch and current master. Both were using liveBackBufferLength of 120

I verified that the ID3 cues are being removed properly 👍

Thoughts on getting this in soon, @johnBartos, @itsjamie, @OrenMe ?

Bump

[itsjamie]

LGTM.

@robwalch targeting this for 0.13.1 with the gap controller code.

Rob brought up a good point that I missed about the new event.