Follow up with with  Issue 872011 .

QuicChromiumPacketReader keeps the assumption that if ProcessReadResult is in progress, no new read should be attempted, i.e., StartReading() should not be called. 

However, it currently exposes an API StartReading which will result a read on the associated socket immediately instead of posting a task in the message loop. That being said, it's conceivable, session could mistakenly call QuicChromiumPacketReader::StartReading() while reader is processing the read result, just like what we hit in  Issue 872011 . 

A solution to this should be changing the current StartReading to a private method StartReadingImpl and exposes the API StartReading to cause the reader to read packets by posting a task to execute the private method.