Refacto current position handling again just to work-around tizen mischievous seek-backs

[peaBerberian]

Tizen "seek-backs"

Tizen devices (mainly samsung TVs) are the only devices on which seek operations is not precize.

On those devices for example, you might want to seek at a given position, let's say 51 seconds, and tizen could actually after media segments are loaded decide to finally play at an earlier position instead, let's say 50 seconds.
The choice actually made by tizen seems to correspond to the closest IDR video frame instead of what the RxPlayer wants, we guess because of performance reasons.

This caused many problems in the RxPlayer as we generally want to seek at a very specific position for very valid reasons, for example it could be because we need the position to be within a specific Period's boundaries or because we need to make sure the current position is after a known audio discontinuity to ensure smooth playback.

The fact that tizen may re-seek back in the past, what we now call "seek-backs", can lead to very problematic player behaviors, such as seeking loops (tizen seeking back, RxPlayer seeking forth) or worse in the recently-seen case, content reloading loops.

The previous strategy was to directly make exceptions, just for Tizen devices, at each place in the code where this seek-back behavior led to problems. After 5 or 6 patches, we thought for many years that we had no remaining issues.

The newly seen issue

However we very recently found out a new rare and subtle issue linked to those same pesky seek-backs, this time when:

1. We're on a Samsung TV
2. The onCodecSwitch loadVideo option is set to reload
3. We're currently playing the very end of a Period with a given codec "A"
4. The very close next Period has an incompatible codec "B"
5. The RxPlayer, seek on the Period with the codec "B", also triggering a reload for the new codec
6. Tizen decides to seek back at the very end of the previous Period with the codec "A"
7. The RxPlayer sees that again, we're at the very end of Period "A", seeks to the very beginning of Period "B", and we're in an infinite loop, yay!

We finally decided to try a general solution which is the point of this PR.

New way of dealing with it

What I decided to do here, was to reinforce a difference between:

1. the HTMLMediaElement's currentTime attribute, which is the position we're actually playing on the media element, and
2. The actual position we want to load the media at

Simply written in the Tizen case, the former will actually be affected by seek-backs and might thus not always reflect what the RxPlayer wants the position to be, but the second will only indicate the position the RxPlayer actually wants to play at.

Then the rest of the RxPlayer code will use one or the other, depending on what it wants to do:

• If the corresponding code has to do with HTML implementation details (e.g. detecting browser playback issues), it will rely on the true currentTime, which may have been affected by Tizen seek-backs
• For the great majority of the code where what we want to do is just knowing which position we want to load and play at, we'll actually rely on the latter.

I've been able to reuse the same 2-positions concept to also simplify the handling of the initial seek performed by the RxPlayer:

• Until it is actually performed (we need the media element to reach a specific readyState before being able to seek), the currentTime is set to 0
• However, the wanted position will be set to the initially-wanted position in that case, as that's the position for which we actually want to load segments.

Why only for the v4?

This is the first bug fix we've implemented only for the v4. We may backport it for the v3 but the code update was big enough and the bug rare enough for me to prefer targeting the v4 first.