Round out polling timestamp

[mjangda]

Rather than a random scatter of timestamps, we can get a much higher cache hit-rate by forcing/normalizing multiple clients to make a request with the same timestamp.

[mjangda]

Lint issues have been fixed.

[paulschreiber]

Per @rogertheriault, this can result in timestamps in the future. Change Math.round() to Math.floor().

[philipjohn]

I made @paulschreiber / @rogertheriault's suggested change and then ran a test. I took a simple Liveblog, opened it on 3 different clients (using different IPs) and proceeded to add new entries. I then looked at the API requests that came in from those clients.

What I saw was multiple clients using the same URLs, with clear 10-second intervals and the start time updating only occassionally. I have listed these request URLs below with readable start and end times.

#	Request URL	Start	End
1	/wp-json/liveblog/v1/9/entries/1536402970/1536403670/	10:36:10	10:47:50
2	/wp-json/liveblog/v1/9/entries/1536402970/1536403680/	10:36:10	10:48:00
3	/wp-json/liveblog/v1/9/entries/1536402970/1536403690/	10:36:10	10:48:10
4	/wp-json/liveblog/v1/9/entries/1536402970/1536403700/	10:36:10	10:48:20
5	/wp-json/liveblog/v1/9/entries/1536403697/1536403710/	10:48:17	10:48:30
6	/wp-json/liveblog/v1/9/entries/1536403697/1536403720/	10:48:17	10:48:40
7	/wp-json/liveblog/v1/9/entries/1536403697/1536403730/	10:48:17	10:48:50
8	/wp-json/liveblog/v1/9/entries/1536403697/1536403740/	10:48:17	10:49:00
9	/wp-json/liveblog/v1/9/entries/1536403697/1536403750/	10:48:17	10:49:10

As is clear, after request no. 4 the start time changes.

After the test, I used wp shell to run WPCOM_Liveblog::get_entries_by_time(1536402970,1536403700); which showed me the response data for request 4. In the data, the latest_timestamp property was set to 1536403696. This is clearly helping to set the new start time for subsequent requests.

Looks like, with the floor() change this PR resolves #489 nicely.

[rogertheriault]

We've (@mjangda actually) noticed that + config.timeDifference; can sometimes add a few minutes to the timestamp, if the page was cached. So that may be part of the problem when there's an active cache - it doesn't show up too well when just testing the individual requests. It might be necessary to drop that bit. Even without it, we've seen cases where there were still some future timestamps...

[paulschreiber]

I was told to remove + config.timeDifference and did in my copy. Let's do that here, too.

[philipjohn]

I've pushed the removal of the + config.timeDifference which looks good. I'm going to go ahead and merge seeing as we all seem to be on the same page on this.