Looking at a recent failed repair task, I see that
an attempt to repair servo included this error:
	START	----	repair.reboot	timestamp=1497985697	localtime=Jun 20 12:08:17	
		FAIL	----	repair.reboot	timestamp=1497985706	localtime=Jun 20 12:08:26	command execution error
  * Command: 
      /usr/bin/ssh -a -x  -o ControlPath=/tmp/_autotmp_wHIEnCssh-master/socket
      -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o
      BatchMode=yes -o ConnectTimeout=30 -o ServerAliveInterval=180 -o
      ServerAliveCountMax=3 -o ConnectionAttempts=4 -o Protocol=2 -l root -p 22
      chromeos4-row13-rack1-host8-servo " if type \"logger\" > /dev/null 2>&1;
      then logger -tag \"autotest\" \"server[stack::repair|run|wrapper] ->
      ssh_run(/usr/share/vboot/bin/set_gbb_flags.sh 0)\";fi;
      /usr/share/vboot/bin/set_gbb_flags.sh 0"
  Exit status: 1
  Duration: 4.61115598679
  
  stdout:
  Calibrating delay loop... OK.
  stderr:
  flashrom v0.9.4  : f15c2fa : May 13 2017 03:58:01 UTC on Linux 4.4.4 (armv7l)
  flashrom v0.9.4  : f15c2fa : May 13 2017 03:58:01 UTC on Linux 4.4.4 (armv7l)
  delay loop is unreliable, trying to continue No EEPROM/flash device found.
  Note: flashrom can never write if the flash chip isn't found automatically.
	END FAIL	----	repair.reboot	timestamp=1497985706	localtime=Jun 20 12:08:26	

For servo repair, we shouldn't be invoking set_gbb_flags.sh like
this (or at all).

The root cause is that server.hosts.servo_repair._ServoRebootRepair
inherits from server.hosts.repair.RebootRepair.  The RebootRepair
base class now calls "set_gbb_flags" for the sake of CrosHost, so
we need to separate the Servo version of this class from its parent
class, i.e.
  * Create an abstract RebootRepair that (only) reboots a host
    in the context of a RepairAction.
  * Extend _CrosRebootRepair from RebootRepair to invoke
    "set_gbb_flags" for Cros DUTs.
  * Extend _ServoRebootRepair from RebootRepair to properly reboot
    a servo host without triggering "set_gbb_flags".