Simplify the communication between the browser host and iframe

[natebosch]

Currently there are 3 hops during startup.

• iframe (postMessageChannel) posts a message to parent
• parent posts message back to iframe
• Communication can run over the private channel wired up to the other test infrastructure by forwarding from the frame and from the host

This communication all happens an an opaque way, especially on remote CI infrastructure, and may be involved with some flakes that we see in a few places where browser tests never start. We should simplify the communication, and add some logging to see if we can get any insight into the cause of the flakes.

A better pattern would be

• iframe posts the MessageChannelPort to the parent and wires it up to the channel.
• host receives the port and wires it up to the channel. Start forwarding messages when the channel is ready instead immediately forwarding to a callback that waits for the channel to be ready.

Separately, we have some unnecessary legacy behavior with extra messages that turned out to be a no-op round trip sending a signal back to the calling code to continue. We can clean that up in the same pass - I've already removed the usage in source but have not yet released that version internally.

#2061 does the full refactoring, and would be safe to land if this was the only test runner. As mentioned in #2061 (comment) we will need to do this in multiple steps with backwards compatibility along the way because there is another copy of both sides of the implementation, and we cannot roll them all atomically.

Somewhat interesting side note - Even though the flutter use case doesn't pin package:test as a dependency, they reach into the pub solve within the flutter SDK to find the version of test pinned through a dev_dependency and use that version of the compiled host js.

My plan is to:

• update this test runner host.dart side to handle either behavior - it receives the first message and can know what version of the iframe it is communicating with.
• Update the internal copy of the host to handle either behavior.
• land in google3 and publish.
• roll the test runner into flutter.
• Update flutter's copy of postMessageChannel to the new behavior.
• Update test runner copy of postMessageChannel to the new behavior.
• Remove support for the old behavior in this test runner host.dart.
• land and publish again.
• Remove support for the old behavior in the internal runner host.

@jakemac53 - do you have any concerns?

[natebosch]

I do not plan to have local tests validating backwards compatibility at any step here since I don't expect any step to be long lived. I plan on manually verifying cross compatibility as we go. Existing tests within each of the three relevant repositories will ensure that the used set of cross compatibilities are working as we use them, so the risk is only that some steps might need multiple PRs if a problem surfaces trying to land it in the next repo.

[natebosch]

reach into the pub solve within the flutter SDK

We saw in a recent issue changing some code in test_api which impacted usage in flutter_test that some flutter users are running flutter update-packages and corrupting their SDK pub solve - I think with this plan even those users would be safe from this particular cross compatibility issue because the plan is already to make the new test backwards compatible with the current flutter_test for at least one release, and update-packages shouldn't ever downgrade test to a version that wouldn't be compatible.