Stop attempting to run a mysqldump before migrations

The pre-migration mysqldump was added so we would have a backup to
restore to in case a migration went south. However, given the size of
the DB, and the times involved in both writing a backup and restoring
from one (which takes days) this isn't very practical. Also, whether
there is enough local disk on logstash.o.o where this will be run is
not entirely clear. Given this we should just abandon this idea before
we begin and just pray that a migration never goes south. (which is
probably a terrible assumption given that I've written most of them)

If/when we consider the data in the subunit2sql database valuable
enough to warrant backing up we can investigate using a real
multi-region periodic backup solution.

Change-Id: I59fb90811d2c9d300d6be7cb876997fd3f35d9bd

manifests/server.pp

@@ -40,19 +40,11 @@ class subunit2sql::server (
     content => template('subunit2sql/subunit2sql-my.cnf.erb'),
   }
 
-  exec { 'backup_subunit2sql_db':
-    command     => "set -o pipefail; mysqldump --defaults-file=/etc/subunit2sql-my.cnf --opt ${db_name} | gzip -9 > /opt/subunit2sql.sql.gz",
-    path        => '/usr/local/bin:/usr/bin:/bin/',
-    subscribe   => Package['subunit2sql'],
-    require     => File['/etc/subunit2sql-my.cnf'],
-    refreshonly => true,
-    timeout     => 1800,
-  }
-
   exec { 'upgrade_subunit2sql_db':
     command     => 'subunit2sql-db-manage --config-file /etc/subunit2sql.conf upgrade head > /var/log/subunit2sql_migration.log 2>&1 &',
     path        => '/usr/local/bin:/usr/bin:/bin/',
-    subscribe   => Exec['backup_subunit2sql_db'],
+    require     => File['/etc/subunit2sql-my.cnf'],
+    subscribe   => Package['subunit2sql'],
     refreshonly => true,
     timeout     => 0,
   }