ConnectivityConstraintTest: Fix wifi state check in tearDown()

Commit 56e4387fe0572 ("Wait for wifi previous state to actually be
restored") introduced logic that calls setWifiEnabled(mInitialWifiState)
and then waits for a broadcast intent confirming a state change.  However,
if the current state is the same as the initial state, there is no
guarantee that a state change intent will be generated; per the API
specification the framework is free to treat that setWifiEnabled()
call as a no-op.  Therefore the test is relying on undocumented,
implementation-dependent behavior.

Add a check to skip this logic if the current state is the same as the
expected state.

Bug: 30681096
Change-Id: Id6271364e0b43224b8337bb4171886ad2879c93e
diff --git a/tests/JobScheduler/src/android/jobscheduler/cts/ b/tests/JobScheduler/src/android/jobscheduler/cts/
index a82c17c..a7c7003 100644
--- a/tests/JobScheduler/src/android/jobscheduler/cts/
+++ b/tests/JobScheduler/src/android/jobscheduler/cts/
@@ -76,6 +76,9 @@
     public void tearDown() throws Exception {
         // Ensure that we leave WiFi in its previous state.
+        if (mWifiManager.isWifiEnabled() == mInitialWiFiState) {
+            return;
+        }
         NetworkInfo.State expectedState = mInitialWiFiState ?
             NetworkInfo.State.CONNECTED : NetworkInfo.State.DISCONNECTED;
         ConnectivityActionReceiver receiver =