Fix flaky URLConnectionTest.serverShutdownOutput test

There are usually 2 requests sent to '/b' during the test:
square#1 on the busted connection, attempting reuse
square#2 on a new connection

On successful runs, the server records square#1 and then square#2 and adds them to the queue in that order.

On failed runs, the server starts reading request square#1 before square#2, but there is a context switch, and it finishes reading square#2 before square#1, recording them in that order. Since square#1 is the last to be recorded, the test incorrectly uses it to assert that the sequence number is 0. Since square#1 was the second to be received on the busted connection, it has a sequence number of 1 so the test fails.

The fix asserts that either square#1 or square#2 has a sequence number of 0.

okhttp-tests/src/test/java/okhttp3/URLConnectionTest.java

@@ -469,12 +469,14 @@ private void testServerClosesOutput(SocketPolicy socketPolicy) throws Exception
     assertContent("This comes after a busted connection", connection2);
 
     // Check that a fresh connection was created, either immediately or after attempting reuse.
+    // We know that a fresh connection was created if the server recorded a request with sequence
+    // number 0. Since the client may have attempted to reuse the broken connection just before
+    // creating a fresh connection, the server may have recorded 2 requests at this point. The order
+    // of recording is non-deterministic.
     RecordedRequest requestAfter = server.takeRequest();
-    if (server.getRequestCount() == 3) {
-      requestAfter = server.takeRequest(); // The failure consumed a response.
-    }
-    // sequence number 0 means the HTTP socket connection was not reused
-    assertEquals(0, requestAfter.getSequenceNumber());
+    assertTrue(
+        requestAfter.getSequenceNumber() == 0
+            || server.getRequestCount() == 3 && server.takeRequest().getSequenceNumber() == 0);
   }
 
   enum WriteKind {BYTE_BY_BYTE, SMALL_BUFFERS, LARGE_BUFFERS}