tree 6bc219b5cc8e4fb7f3b6cfb254fe60cfcdbfd938
parent 85d5b82605efd1e6c90cb0fcc48cbd3fa8513b66
author Wade Guthrie <wdg@chromium.org> 1374086635 -0700
committer ChromeBot <chrome-bot@google.com> 1374866143 -0700

shill: Cleans-up scan state machine to address field trial anomalies.

The progressive scan field trial shows a few scan-to-connect times that
extend much, much longer than expected (5% of one study group shows
times that extend to multiple hours).  I suspect that various timeouts
in the scan/connect process (including the user being too frustrated to
continue) would terminate this process long before we reached an hour
and, therefore, that these anamolies are a function of measurement
rather than operational problems.  This would suggest that some
operations that should terminate the scan state machine aren't being
caught and, consequently, that occasionally some wifi connections are
being linked to previous, unrelated, scans.

This CL explores this possibility by rearranging the SetScanState calls
to follow pending_service_ (an indicator of scan/connect state that has
gotten a lot of testing and time in the field).  This has the added
benefit of insuring that different code that expresses the state of
the scan/connect mechanism track each other more closely.

One ramification of this CL is that scan-to-connect and
scan-to-not-found state transitions occur earlier than before.  The
transition was moved to the actual cause of the transition (to the call
to SetPendingService, for instance) rather than a convenient spot to
view it (in ProgressiveScanTask).

In certain cases (in PendingTimeoutHandler, for instance), SetScanState
calls had to be moved relative to existing calls to SetPendingState
(which now calls SetScanState) in order to reflect the actual scan state
correctly.  Similar reasoning instigated the creation
kScanTransitionToConnecting to correctly document the scan state if,
during the scan/connect process, we try to connect to a service that is
not the pending_service_.

Another change resets the WiFi connect timer (just as we reset the WiFi
scan timer) when the scan state reaches 'kScanIdle'.

BUG=chromium:260759
TEST=unittest

Change-Id: Ib1c559b27d91df5b7408a42b187fb67cf03c8784
Reviewed-on: https://gerrit.chromium.org/gerrit/62131
Reviewed-by: mukesh agrawal <quiche@chromium.org>
Commit-Queue: Wade Guthrie <wdg@chromium.org>
Reviewed-by: Wade Guthrie <wdg@chromium.org>
Tested-by: Wade Guthrie <wdg@chromium.org>