VPAAMP-477: a single curl 56 on manifest refresh causes manifest refr…

[shripadbpersonal]

…esh attempts to stop (#1531)

• VPAAMP-477: a single curl 56 on manifest refresh causes manifest refresh attempts to stop

After a download failure mMPDData->mIsLiveManifest is false (only set during successful parse), so refreshNeeded was never set and the downloader thread exited on the first refresh error.

Add an else-if branch below the existing timeout/COULDNT_CONNECT fast-retry block to catch all other non-success error codes (including CURLE_RECV_ERROR / curl 56) when past the first download. Sets a 500 ms retry interval and keeps the refresh loop alive so the next manifest fetch is attempted rather than killing the downloader thread.

The !firstDownload guard ensures tune-time failures still exit the loop immediately, preserving existing behaviour for initial tune failures.

• VPAAMP-477: add recovery logging and fix unnecessary 500ms interval override

Two follow-up improvements to the manifest refresh retry fix:

1. Add downloadFailed flag to track transitions from failure back to success. Set in both the timeout/COULDNT_CONNECT branch and the new transient-error branch; cleared with a WARN log when the next manifest fetch succeeds. This makes it easy to count recovery events in production logs independently of the per-failure curl error logs.

2. Remove the mRefreshInterval=MIN_DELAY_BETWEEN_PLAYLIST_UPDATE_MS override from the transient-error (curl 56 / non-timeout) branch. mRefreshInterval is a member that persists across iterations and is set by getMeNextManifestDownloadWaitTime() on every successful parse, so it already holds the correct MPD-derived interval. The 500ms override is appropriate for timeout/COULDNT_CONNECT (fast connectivity detection) but not for transient receive errors where the stream's own minimumUpdatePeriod should be respected.

• VPAAMP-477: restore tuneUrl effective URL update dropped in previous commit

The tuneUrl = mMPDData->mMPDDownloadResponse->sEffectiveUrl assignment was accidentally removed during refactoring. Without it, redirects are not followed on subsequent refreshes — the downloader keeps hitting the original URL instead of the post-redirect effective URL.

• fix: use 500ms fast-retry for non-timeout manifest download errors

• Change preProcessCallback type from std::functionstd::string() to std::function<std::pairstd::string,int()> so callers can supply a specific curl/HTTP error code rather than always producing CURLE_OPERATION_TIMEDOUT
• In the else-if retry block, use a local fastRetry = 500ms instead of mRefreshInterval; mRefreshInterval is not permanently overwritten so the MPD-derived update period is preserved after recovery
• Update SendManifestPreProcessEvent in priv_aamp and all fakes/mocks to return pair<string,int> with CURLE_OPERATION_TIMEDOUT on empty
• Add L1 regression test AampMPDDownloader_LiveRefreshRetriesWhenFailureIsCurlRecvError: injects CURLE_RECV_ERROR after first successful live fetch and asserts the downloader loop continues producing further refresh attempts

(cherry picked from commit 13178c3)