Fix HLS download failure when EXT-X-DEFINE variables are referenced in media playlist segment URLs

[prashant9934]

PR Description:

Summary

Fixes HLS download failures for streams where the multivariant playlist defines
variables via #EXT-X-DEFINE:NAME=...,VALUE=... and media playlists reference
them in segment URLs without an explicit #EXT-X-DEFINE:IMPORT=... tag.

Fixes #3258

Problem

HlsDownloader (via SegmentDownloader) uses a single HlsPlaylistParser()
instance constructed with HlsMultivariantPlaylist.EMPTY. This instance first
parses the multivariant playlist, then parses each media playlist. However, the
parsed multivariant playlist was never stored back into the parser instance.

When media playlists are subsequently parsed, multivariantPlaylist is still
EMPTY, so:

• variableDefinitions is unavailable during replaceVariableReferences()
• {$variable} references in segment URLs pass through unsubstituted
• Downloads fail with HTTP errors on malformed URLs
• HlsMediaPeriod.getStreamKeys() crashes with IndexOutOfBoundsException

During playback this works correctly because HlsPlaylistTracker constructs
the parser with the real multivariant playlist.

Fix

HlsPlaylistParser.java:

• Make multivariantPlaylist field non-final
• After parsing a multivariant playlist in parse(), store it in the instance
• Subsequent parseMediaPlaylist() calls on the same instance now have access
  to the correct variableDefinitions for variable substitution

HlsMediaPeriod.java:

• Add bounds checks in getStreamKeys() to prevent IndexOutOfBoundsException
  when redundantGroupIndicesPerWrapper has an empty array or when
  renditionRedundantGroupIndex exceeds the redundant groups list size

Testing

Tested with an HLS stream using:

#EXT-X-DEFINE:NAME="awsContentSegmentPrefix",VALUE="https://cdn.example.com/"

in the multivariant playlist, with media playlist segment URLs referencing
{$awsContentSegmentPrefix} directly. Download completes successfully with
variables resolved. Existing playback behavior is unchanged

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[marcbaechinger]

Thanks. Please can you file the CLA? We can't process this before the CLA requirements.

As you are saying that the problem manifests in download use cases only. Would you be able to craft a unit test that demonstrates the failure and verifies the fix? That's what we have to do anyway internally when processing your fix, and if you are able to provide this, this may make taking the pull a bit quicker. Thanks for considering adding such a unit test. We'd need the CLA in any case.