fix(FEC-10275): Bumper incorrectly recognised as ad

[dan-ziv]

Description of the Changes

Player's getAd() API shouldn't return Ad object while ad is only loaded, this can cause issues when IMA loads its ads so early:

1. AD_LOADED is triggered while media is playing - getAd() returns ad but no ad is currently playing.
2. AD_LOADED is triggered while another ad/bumper is playing - getAd() returns the wrong ad.

Solution:

• To access the loaded ad from the player's API, use getPendingAd() API. In such way, we are solving the above issues:

1. AD_LOADED is triggered while media is playing - getAd() returns nothing, getPendingAd() returns the loaded ad.
2. AD_LOADED is triggered while another ad/bumper is playing - getAd() returns the current ad, getPendingAd() returns the next ad.

• change playAdsWithMSE implementation to listen to AD_LOADED event and only if the pending ad is linear, listen to ad break start to run the playAdsWithMSE logic.

CheckLists

• changes have been done against master branch, and PR does not conflict
• new unit / functional tests have been added (whenever applicable)
• test are passing in local environment
• Travis tests are passing (or test results are not worse than on master branch :))
• Docs have been updated

[yairans]

@dan-ziv What's about ad pod which has adloaded with no adbreakstart after (from the second ad in the pod). You can add check this is the first ad in pod using ad.index/position. otherwise dont listen to asbreakstart

[Yuvalke]

@dan-ziv same issue as I mentioned in playkit, postroll IMA+BUMPER postroll.
you'll get the incorrect pending ad since IMA post-roll loads before bumper, on bumper ad start playing getPendingAd will return null and needs to return IMA postroll.

[dan-ziv]

Just because I added pendingAd this issue will reflect in an API call. But it's a separate issue that has been around all along: you'll trigger AD_LOADED event twice with a different ad payload.
So, anyway, I think we need to handle it in a different ticket and not overload it here. We can remove in the meanwhile the pendingAd API to avoid this issue. @OrenMe @yairans what do u think?

[Yuvalke]

Agree, if you keep the pendingAd API it should be fixed since it won't return the correct value.

[yairans]

I would remove it as no one is using it

[OrenMe]

So agreed - let's remove from here and open ticket to handle the next ad issue.
I think it is ok to have a nextAd object with this exact same logic as you added here.
This way we have a flow where when ad is loaded you can get it in getnextAd and when it starts we clear nextAd and update the _ad object that can be retrieved in getAd.
And when another ad get's loaded it will be populated in the _nextAd - this can happen in several ways, if this is an ad pod then while current ad is playing the next will be loaded or for IMA specifically when last midroll finish and there is a postroll the postroll is already loaded.