Latest results here:
https://stainless.corp.google.com/search?test=%5Eautoupdate%5C_NonBlockingOOBEUpdate%5C.delta%24&exclude_non_release=true&exclude_cts=true&col=build&row=model&view=matrix&first_date=2018-04-07&last_date=2018-04-13

We found out that when we powerwash a device and then do the OOBE update to a non critical payload, update engine gives error kNonCriticalUpdateInOOBE

However, when we just clear local state (which is enough to get the device to show the OOBE welcome page again) update engine's OOBE complete state is preserved and so it does not give an error and instead starts an update. It seems like update_engine does not realize that it is an update during OOBE

Attached are the logs for OOBE update non critical after 
1. powerwash
2. removing local state 

Deleted: update engine log: OOBE non critical update after removing Local State.txt 42.1 KB

update engine log: OOBE non critical update after removing Local State.txt 42.1 KB View Download

Deleted: update engine log: OOBE non critical update after powerwash.txt 20.7 KB

update engine log: OOBE non critical update after powerwash.txt 20.7 KB View Download

During an autotest to get to OOBE we do this:

chrome.Chrome(auto_login=False) 
which looks like it ends up calling this:
https://cs.corp.google.com/clankium/src/chrome/browser/resources/chromeos/login/login_shared.js?type=cs&q=showOobeUI&l=101

Which just makes the OOBE be shown. It doesn't clear anything. So it makes sense that the test would fail when it is not run directly after provisioning. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/autotest/+/3a8f5724a8893fb09eb776548032f7ee3a95aeb9

commit 3a8f5724a8893fb09eb776548032f7ee3a95aeb9
Author: David Haddock <dhaddock@chromium.org>
Date: Sat Apr 14 04:37:44 2018

Reset TPM and delete all state files before running OOBE update tests.

At the moment, OOBE AU autotests will run differently depending on how
long it has been since a DUT was provisioned. If the tests are run directly
after provisioning they will run as expected. If they are run after a
different autotest has logged into Chrome they will be run in a "nearly new"
state. This "nearly new" state is a result of chrome.Chrome(auto_login=False).
This resets some settings and makes the OOBE welcome screen appear. However,
update_engine will still believe we are already passed OOBE and won't behave
_exactly_ like it would for a new user.

This CL fixes that since we want to test the flow for users turning on a
device for the first time.
https://www.youtube.com/watch?v=8Tl-kOcnn1U

BUG= chromium:832902 
TEST=autoupdate_ForcedOOBEUpdate.delta
TEST=autoupdate_NonBlockingOOBEUpdate.delta

Change-Id: I2a8b6d9a1a8b1cc88ba21a43e0d66f76a4948247
Reviewed-on: https://chromium-review.googlesource.com/1013145
Commit-Ready: David Haddock <dhaddock@chromium.org>
Tested-by: David Haddock <dhaddock@chromium.org>
Reviewed-by: Katherine Threlkeld <kathrelkeld@chromium.org>

[modify] https://crrev.com/3a8f5724a8893fb09eb776548032f7ee3a95aeb9/server/site_tests/autoupdate_NonBlockingOOBEUpdate/autoupdate_NonBlockingOOBEUpdate.py
[modify] https://crrev.com/3a8f5724a8893fb09eb776548032f7ee3a95aeb9/server/site_tests/autoupdate_ForcedOOBEUpdate/autoupdate_ForcedOOBEUpdate.py