BigPipeTest::assertSetsEqual does not assert anything

Rerolled patch #8

+++ b/core/modules/big_pipe/tests/src/Functional/BigPipeTest.php
@@ -338,7 +338,7 @@ protected function assertBigPipeResponseHeadersPresent() {
-    $this->assertSetsEqual(array_keys($expected_big_pipe_nojs_placeholders), array_map('rawurldecode', explode(' ', $this->drupalGetHeader('BigPipe-Test-No-Js-Placeholders'))));
+    $this->assertNotEqualsCanonicalizing(array_keys($expected_big_pipe_nojs_placeholders), array_map('rawurldecode', explode(' ', $this->drupalGetHeader('BigPipe-Test-No-Js-Placeholders'))));

We've changed the assertion from saying things are equal to saying they're not equal...

Was the test wrong before? If so, could the issue summary be updated to explain how?

So doing some git and d.o archaeology leads us to #2469431: BigPipe for auth users: first send+render the cheap parts of the page, then the expensive parts where this test was first introduced. A refactor in comment #244 accidentally removed the assertion from assertSetsEqual(), as per the interdiff:

   protected function assertSetsEqual(array $a, array $b) {
-    $a_set = $a;
-    sort($a_set);
-    $b_set = $b;
-    sort($b_set);
-    return $this->assertEqual($a_set, $b_set);
+    return count($a) == count($b) && !array_diff_assoc($a, $b);
   }

Therefore it seems the intent was to do what assertEqualsCanonicalizing() now does, and switching to that as in #17 seems the right thing to do.

Next step is to figure out why one of the tests is now failing, and fix that.

So there are multiple issues that have touched that test since it was first introduced, some of the ones that could have made a difference here are:

#2678568: Ensure good UX & DX even when A) rendering of placeholder fails, B) some response event subscriber fails
#2712935: Messages are not rendered last, meaning those messages set within placeholders only appear on the next request
#2657684: Refactor BigPipe internals to allow a contrib module to extend BigPipe with the ability to stream anonymous responses and prime Page Cache for subsequent visits

I guess if all else fails we can roll back to older versions of core, fix the test assertion there, and see if we can figure out whether this has always been broken or if one of those issues broke it. This would normally be a good use of git bisect except that halfway through we change from WebTestBase to BrowserTestBase.