Warning "The log was not applied to the intended LSN" should optionally be an error

xtrabackup: ########################################################
xtrabackup: # !!WARNING!! #
xtrabackup: # The transaction log file is corrupted. #
xtrabackup: # The log was not applied to the intended LSN! #
xtrabackup: ########################################################

From xtrabackup.cc (2.2.8) starting at line line 6032

 if (innobase_log_arch_dir)
  srv_start_lsn = log_sys->lsn = recv_sys->recovered_lsn;

 /* Check whether the log is applied enough or not. */
 if ((xtrabackup_incremental
      && srv_start_lsn < incremental_last_lsn)
     ||(!xtrabackup_incremental
        && srv_start_lsn < metadata_last_lsn)) {
  msg(
"xtrabackup: ########################################################\n"
"xtrabackup: # !!WARNING!! #\n"
"xtrabackup: # The transaction log file is corrupted. #\n"
"xtrabackup: # The log was not applied to the intended LSN! #\n"
"xtrabackup: ########################################################\n"
      );
  if (xtrabackup_incremental) {
   msg("xtrabackup: The intended lsn is " LSN_PF "\n",
       incremental_last_lsn);
  } else {
   msg("xtrabackup: The intended lsn is " LSN_PF "\n",
       metadata_last_lsn);
  }
 }

Besides the possible bug that caused this, we should consider an option to make this event either a warning or an error, so innobackupex will not return 0 as it does now, because the backup could in fact be corrupt.

I'm not entirely sure what an option name could be, but something like --too-short-log-apply-handle=warning|error would work I guess.