Use CASE for our "Tests" test suite.

There are four changes here:

1) When doing onnetwork commissioning, make sure to run the part of
the commissioning state machine that is meant to run on the
operational network, starting with the mdns resolution of the device
operational address.  This ensures that we put ourselves into a state
where we know the operational cert is fully provisioned on the device
and we can talk to it via CASE.

2) Fix the fabric id in the script's pairing command to match the
fabric id all-clusters-app advertises, so our operational discovery
looks for the right thing.

3) Ensure that we actually start operational advertisement when we get
a new opcert.  Just restarting our mdns server does not do that, due
to #7911

4) Don't fail out on UpdateAddress attempts when there is no
connection; that's not an error condition and should not be
communicated as such to consumers.

examples/chip-tool/commands/pairing/PairingCommand.cpp

@@ -110,11 +110,15 @@ void PairingCommand::OnPairingComplete(CHIP_ERROR err)
     if (err == CHIP_NO_ERROR)
     {
         ChipLogProgress(chipTool, "Pairing Success");
-        SetupNetwork();
+        err = SetupNetwork();
     }
     else
     {
         ChipLogProgress(chipTool, "Pairing Failure: %s", ErrorStr(err));
+    }
+
+    if (err != CHIP_NO_ERROR)
+    {
         SetCommandExitStatus(err);
     }
 }
@@ -156,8 +160,10 @@ CHIP_ERROR PairingCommand::SetupNetwork()
     {
     case PairingNetworkType::None:
     case PairingNetworkType::Ethernet:
-        // Nothing to do
-        SetCommandExitStatus(err);
+        // Nothing to do other than to resolve the device's operational address.
+        err = UpdateNetworkAddress();
+        VerifyOrExit(err == CHIP_NO_ERROR,
+                     ChipLogError(chipTool, "Setup failure! Error calling UpdateNetworkAddress: %s", ErrorStr(err)));
         break;
     case PairingNetworkType::WiFi:
     case PairingNetworkType::Thread:

scripts/tests/test_suites.sh

@@ -88,7 +88,7 @@ for j in "${iter_array[@]}"; do
         # the data is there yet.
         background_pid="$(</tmp/pid)"
         echo "          * Pairing to device"
-        out/debug/standalone/chip-tool pairing onnetwork 1 20202021 3840 ::1 11097
+        out/debug/standalone/chip-tool pairing onnetwork 0 20202021 3840 ::1 11097
         echo "          * Starting test run: $i"
         out/debug/standalone/chip-tool tests "$i"
         # Prevent cleanup trying to kill a process we already killed.

src/app/clusters/operational-credentials-server/operational-credentials-server.cpp

@@ -348,7 +348,7 @@ bool emberAfOperationalCredentialsClusterAddOpCertCallback(chip::app::Command *
     // can't just wait until we get network configuration commands, because we
     // might be on the operational network already, in which case we are
     // expected to be live with our new identity at this point.
-    chip::app::Mdns::StartServer();
+    chip::app::Mdns::AdvertiseOperational();
 
 exit:
     emberAfSendImmediateDefaultResponse(status);

src/controller/CHIPDevice.cpp

@@ -390,7 +390,14 @@ CHIP_ERROR Device::UpdateAddress(const Transport::PeerAddress & addr)
     ReturnErrorOnFailure(LoadSecureSessionParametersIfNeeded(didLoad));
 
     Transport::PeerConnectionState * connectionState = mSessionManager->GetPeerConnectionState(mSecureSession);
-    VerifyOrReturnError(connectionState != nullptr, CHIP_ERROR_INCORRECT_STATE);
+    if (connectionState == nullptr)
+    {
+        // Nothing needs to be done here.  It's not an error to not have a
+        // connectionState.  For one thing, we could have gotten an different
+        // UpdateAddress already and that caused connections to be torn down and
+        // whatnot.
+        return CHIP_NO_ERROR;
+    }
 
     mDeviceAddress = addr;
     connectionState->SetPeerAddress(addr);