xtrabackup_56 can fail on prepare if log files > 4G used on source server

The patch to support 5.6 added support for log files > 4G. However that code was incomplete. When xtrabackup adjusts the log header so recovery can later find the record it needs, we now do this:

 mach_write_to_4(log_buf + LOG_CHECKPOINT_1
   + LOG_CHECKPOINT_OFFSET_LOW32,
   LOG_FILE_HDR_SIZE + (ulint) ut_dulint_minus(max_lsn,
   ut_dulint_align_down(max_lsn,OS_FILE_LOG_BLOCK_SIZE)));

i.e. that code only overwrites the low 32 bits of LOG_CHECKPOINT_OFFSET (which is used by recovery to calculate file offsets from LSN), but it leaves the high 32 bits intact. Which means if the server log happened to contain a non-zero value in LOG_CHECKPOINT_OFFSET_HIGH32 at the time the backup was started (which is only possible with log files > 4G), InnoDB recovery on xtrabackup --prepare will be using incorrect file offsets.

The fix is to also overwrite LOG_CHECKPOINT_OFFSET_HIGH32 with 0 in xtrabackup_56.