Hackish bug fix: Video entity downloads keep hanging because too many entities of same timestamp

Summary: Increased max_logs to 10000 (not sure if this will break anything else), will notify if 10000 is still not enough

Test Plan: Ran local tests with script test.py, can be found on analytics machine in tmp_analytics/src

Reviewers: jace

Differential Revision: http://phabricator.khanacademy.org/D2970
Got rid of extra variable prev_start, fixed comment

Note: The code looks a *bit* more involved because I have to do some work to retrieve the timestamp of the first entity. It may be worth discussing whether calling calling the constructor EntityProto every time and this extra code is preferable to maintaining an extra prev_start variable, though one advantage is that this extra code only applies to the case when the response list is maxed out

Test Plan: Ran test.py in tmp_analytics/src using a small max_logs value and it broke out of the infinite loop properly
Directly calling .isoformat() instead of date_util.to_iso_format to avoid truncation of microseconds, fixed comment describing fix for timeout problem

Test Plan: Confirmed in python shell that .isoformat() doesn't truncate microseconds, ran test.py in tmp_analytics/src and nothing bad happened
Arbitrarily changing max_logs to 10000 earlier was too much, reverted to original 1000 and introduced new, more elegant fix to fetch_entities for timeouts

Test Plan: File was reverted to the current production version
Was comparing timestamps down to the second to detect the timeout error, but now we're querying by microsecond

Test Plan: Won't really be able to legitimately test until changes to api are pushed
Bug fix as noted in review, added "Z" to ISO timestamp for UTC, got rid of note about seconds/microseconds in comment

Test Plan: Worked fine for seconds via tmp_analytics/test.py, but will have to wait for change in request_handlers.py to get pushed before confirming that microseconds work