fix: Fix HLS lazy-loading with DRM

[joeyparrish]

Now that DRM info is only parsed after playback has begun, the manifest parser needs to communicate back to the other components that new DRM info is available after lazy-loading a playlist.

Closes #4622

[joeyparrish]

New test cases to follow.

[github-actions]

Incremental code coverage: 84.38%

[avelad]

Tested locally and it works fine

[avelad]

@joeyparrish This fix does not interfere with the development of #917, does it?

Note: the stream of the issue has EXT-X-SESSION-KEY

[joeyparrish]

@joeyparrish This fix does not interfere with the development of #917, does it?

I don't think it will.

[joeyparrish]

Some additional expectations added to existing tests.

[avelad]

Incremental code coverage: 84.38%

The coverage is low, @joeyparrish do you want increase it?

[joeyparrish]

Incremental code coverage: 84.38%

The coverage is low, @joeyparrish do you want increase it?

The test changes just added newDrmInfo checks at the level of the HLS parser, but the callback for newDrmInfo inside Player is uncovered. In fact, basically none of the callbacks in the manifest parser's playerInterface are covered by tests. I think this is because when we run playback tests that exercise Player, we're using a fake manifest parser that doesn't use that interface at all.

The callbacks in the ManifestParser playerInterface are mostly very very simple, just delegating to one private Player method. newDrmInfo is slightly more complex, in that it has two calls and three null checks, but it's still basically just delegating to processDrmInfos_, which is covered.

So I think it's good enough under the circumstances.