Recently, a raft of broken DUTs were found to have downloaded and
installed production firmware and OS software, leaving them untestable,
and needing manual recovery.

The failure was traced to this sequence of events (see  crbug.com/877107#c52 ):
1. The test creates a new lsb-release at /mnt/stateful_partition/etc/lsb-release. This lsb-release points to a devserver.
2. The test starts a forced update at OOBE.
3. The test fails (e.g the update started too slowly)
4. The new lsb-release file is deleted as part of the test cleanup()
5. The DUT finishes the update in the background.
6. It automatically reboots when the update is finished. (This is normal for OOBE updates).
7. The DUT reboots back to the OOBE update screen and does another update check (this happens so the DUT can successfully deal with stepping stones).
8. Since we deleted the lsb-release it makes the request to production omaha
9. Since we are running a REALLY old build (It is an R65 build linked to in comment #50), the production omaha says there is a build and returns the latest serving stable build.

We need to fix the autoupdate_ForcedOOBEUpdate test so that the chain
above will be definitively broken during test cleanup.

Ideally, this fix should be merged all the way back to the oldest release
still in use by lakitu; see bug 881376.