fix: handle multiple strings that look like they might be JSON

[achingbrain]

The test output can have occurrences of { that aren't the string we are looking for, eg:

dialer-1    | test browser
dialer-1    | [JavaScript Error: "Clear-Site-Data header found. Unknown value “"cache"”." {file: "http://127.0.0.1:34451/" line: 0}]
dialer-1    | [JavaScript Error: "Clear-Site-Data header forced the clean up of “cookies” data." {file: "http://127.0.0.1:34451/" line: 0}]
dialer-1    | [JavaScript Error: "Clear-Site-Data header forced the clean up of “storage” data." {file: "http://127.0.0.1:34451/" line: 0}]

These fail to parse so improve the results parsing by:

1. Try parsing every instance of {...} in the output, not just the first
2. Test the output for the handshakePlusOneRTTMillis and pingRTTMilllis keys

[MarcoPolo]

Why is this on stdout? Shouldn’t these logs be stderr?

[achingbrain]

I’m not sure why it’s on stdout, I agree yes it should be on stderr, but at the same time the function that parses the output should be more robust.

[achingbrain]

There's a fix for this specific issue at hugomrdias/playwright-test#661 but I'm going to merge this because making the detection more robust will help us in the future.

Browsers do sometimes just log uncatchable errors (e.g. https://issues.chromium.org/issues/40069954) which will break this again without the fix here if the message happens to have a { character in it.

We might want to think of a way to transmit results in a less fragile way but that can be done as a follow up if it's desirable.

[MarcoPolo]

We might want to think of a way to transmit results in a less fragile way but that can be done as a follow up if it's desirable.

Reserving stdout for the test results and stderr for everything else (as is convention) would work just fine. My guess is that the test framework we're using just dumps everything to stdout and doesn't distinguish.