Fix to TThriftTransport corruption detection

Fix to TThriftTransport corruption detection

Summary: O_APPEND means that even if the file pointer is in the middle of the file, the next write will go to the end of the file. So when initializing the TThriftTransport to be written to, we need to truncate the file after the last good event.  I'm pretty sure this was what was causing queuemap log corruption when the multiplexer is restarted.

         The corruption doesn't necessarily go away at the next chunk boundary because of the offset being recalculated.  I think it's good to have the offset recalculated, but then we shouldn't use the old chunk boundary data there, but rather use the newly calculated offset to determine the padding (could be an entire chunk, but that's okay -- way better than corruption)

Reviewed By: mcslee

Test Plan: Wrote to a ThriftFile using local scribe instance. Printed it. Then cat'd garbage to it from the command line. Then wrote to it again. Then printed it again.  Seems to work fine, whereas with old scribe binary the later entries were corrupted.

Revert: OK

DiffCamp Revision: 4683

git-svn-id: https://svn.apache.org/repos/asf/incubator/thrift/trunk@665388 13f79535-47bb-0310-9956-ffa450edef68