Tizen: don't directly seek over discontinuity on tizen

[peaBerberian]

We have in the RxPlayer a really reactive discontinuity-detection mechanism which seeks over seen holes in the buffer that won't be filled.

A few subset of the smaller of those holes could theoretically be already be seeked over by the browser/device logic, but to have a faster generalization, we generally seek directly and do not wait to observe what the browser or device will do.

But with Tizen (samsung TVs) this may cause sometimes problems as seeking is approximate on those devices.
We could thus seek over a discontinuity, yet have tizen seeking before it.

We already have a complex code detecting this exact scenario to avoid an infinite loop of discontinuity seeks when that happens, and it works.

Yet we have again seen scenarios when what we called "the seek-back issue" came to bite us: When the discontinuity is encountered at the exact beginning if the content, and we're unlucky enough for that seeking resulting in a 'freeze' (the playback does not advance despite playback conditions being OK), we encountered an infinite buffering on those Tizen devices.

To fix this, @Florent-Bouisset already proposed #1586 which allows to still un-freeze that post-initial-disconinuity-seek freeze by having less conditions to do so, which works, yet which needs to wait for our heuristic to detect a freeze, a rather long multiple-seconds process for now.

As a supplementary logic, I propose here to just let tizen encounter discontinuity for 1 second, before trying to do something. This means we risk to have a 1-2 seconds rebuffering time at real discontinuities, but it prevent all those seek-back issues when the discontinuity is automatically seeked over by the device.