fix(seekbar): don't disable if live tracker's seekable is infinity

[gkatsev]

The seekbar is disabled if the seekable end is Infinity and re-enabled
when it isn't. Instead, we should only disable if seekable end is
Infinity and re-enable only if we disabled for the seekable end.

This auto disabling and re-enabling, without this fix, caused issues
with disabling the progress control since the seekbar got re-enabled.

[gkatsev]

So, spoke with @ldayananda offline.
The issue is that the livetracker affects the seekbar whether we are playing back a live stream or not. Also, this happened every 30ms or so, meaning that if a user tried to disable the progress control, this would potentially come back in and re-enable it. In particular, live tracker defaults seekable end to be Infinity, a reasonable assumption, however, before we end up loading the video, we think that we're at seekable end of infinity and disable the seekbar, which is why just one flag for disableForLive_ wasn't enough. So, here are some potential directions:

• keep track of what the previous state was and then go back to that state instead of always re-enabling. This likely still needs to keep track of disableForLive_ for us to be able to distinguish between a "user-generated" disable or a live tracker disable.
• do what we have now and ignore any live tracker information until video metadata has loaded
• ignore live tracker info if we're not in a live video by checking the duration
• some combination of the above but only on android
• move the disable/enable logic out of update_ and into a durationchange handler. Then specifically target live on android. This means that disable/enable happens once (as we'll get another durationchange if the duration goes from Infinity back to finite number) and a user could call progressControl.disable() and we won't disable/enable it from under them.

[gkatsev]

Another option is to just remove this block as well.

[gkatsev]

So, we've decided to just remove the code in question so it doesn't cause any potential issues. We recommend users on Android overrideNative to use our MSE-based playback engine.