Improve Merge Request polling mechanism

The polling mechanism used in the merge request page often opens a new connection before the first one is received.

This is because the polling used here is using setInterval instead of setTimeout. The former starts a new request every time the interval is met, the latter only starts the second request after the first is finished.

There are in our code base 2 polling functions that already deal with this scenario: backOff and Poll. The Merge Request page is using smartInterval that does not deal with this scenario.

We can improve this either by fixing smartInterval or by using etag polling in this code.

@jschatz1 @timzallmann can we schedule this? We could improve performance with less requests. @smcgivern can we use the etag polling in here? Is backend ready for this?

@filipa the backend for this isn't implemented, and it's non-trivial to add. There is an existing issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/29939#gotchas

Thanks @smcgivern. In that case we can improve this on the Frontend side. It's a simple as using a setTimeout instead of a setInterval.

@jschatz1 what do you think?

This would be discussion @filipa I'll add it for %10.2 and see what happens.

changed milestone to %10.2

As a further improvement of polling mechanism we can implement it in a fading way. Not sure if it applicable here, but idea is following: if user is not active for quit time, switch polling to fading mode: increase polling interval between every request until complete halt after, say, 10 min.

@igor_wiwi we should stop polling whenever the page is inactive, not 100% sure that is happening for the merge request page, thought.

@filipa this had no team label, even though it had a milestone, so it would be invisible when doing Discussion planning! Added one now

added Discussion label

Thank you @smcgivern ;)

assigned to @psimyn

added Deliverable label