Remove no-shuffle from framework tests, part 1: easy cases

[gnprice]

Fixes part of #85160.

I have a draft branch which removes no-shuffle tags from all tests in the framework.

This PR collects up the "easy" fixes:

• In foundations/service_extensions_test, there's a state leak with a simple fix.
• In services/platform_channel_test, there's a state leak. A previous PR Fixed leak and removed no-shuffle tag in platform_channel_test.dart #88432 attempted to fix it, but added cleanup on only some of the tests that needed it, so the problem returned as Tree is closed on many infra failures uploading metrics #88966. Fix it more generically, with tearDown.
• In widgets/widget_inspector_test, the tag was actually already removed in Fix widget inspector null check #120143, but the comment remained. Remove the comment, and update some expectations — because they refer to line numbers in the file's own source code.
• In physics/newton_test, and in three cupertino tests action_sheet_test, date_picker_test, and nav_bar_transition_test, the problem no longer seems to reproduce at all.

For all of these files, I reran the tests after my changes both with the previously failing seed mentioned in the comment, and with 300 random seeds, and they passed every time. That's enough to detect a 1% flake rate with p<.05, and a 2% flake rate with p<.003.

The fixes I've left for separate PRs are those where the fix is more complex, and those where I believe changes in the flutter_test package are appropriate in order to make it easier either to diagnose the problem or to avoid it in the first place.

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[goderbauer]

Thank you sooo much!

LGTM! LGTM! LGTM!

[gspencergoog]

THANK YOU!

[gnprice]

Thanks!

For all of these files, I reran the tests after my changes […] with 300 random seeds, and they passed every time. That's enough to detect a 1% flake rate with p<.05, and a 2% flake rate with p<.003.

Because for some of these test files I couldn't reproduce the problem and don't know what fixed it, I was a bit concerned that one or more of them might just have a low-frequency flake I didn't happen to hit. So I did additional test runs overnight: 500 of them, for a total of 800, all of which passed.

The largest number of tests any of these files have is 104, so if any of them were to have an ordering-dependent flake it's unlikely it would be at a rate lower than 1/104 = 0.96%. (That'd be the probability of a given test coming first, or of coming immediately after another given test.) Running on 800 seeds is enough data to reject that at p<.0004.

[gspencergoog]

Because for some of these test files I couldn't reproduce the problem and don't know what fixed it, I was a bit concerned that one or more of them might just have a low-frequency flake I didn't happen to hit.

Thanks for verifying that. Even if there still is an interdependency or two left in there, it's at a low enough likelihood that we can just deal with it if/when it comes up, which would also expose a seed at which it happens that would let us debug it.