cacheWidth cacheHeight support for canvaskit on web

[alanwutang11]

This PR is the framework side fix for addingcacheWidth and cacheHeight support to web canvaskit.

Previously, cacheWidth and cacheHeight parameters for Image.network were not supported on the web. A fix to add support for canvaskit on the engine side was made here: flutter/engine#38028

This PR, along with the engine side fix, fixes: #88704

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.

[yjbanov]

The expression key.headers?.isNotEmpty ?? false can be saved in a variable and reused both places, which will make the code a little clearer, and save a couple of bytes in payload size.

[alanwutang11]

done

[yjbanov]

nit: style-wise, I'd leave the beginning of the closure on the previous line and remove the first empty line inside:

  testWidgets('Image.network uses cacheWidth and cacheHeight', (WidgetTester tester) async {
    const int expectedCacheHeight = 9;
    ...

[yjbanov]

I'm not sure this class is necessary. It's not passed to the Image widget as an actual provider. Instead, the test calls its testLoad method directly, which means the test could also call image.image.loadBuffer directly with the same effect.

[alanwutang11]

image.image.loadBuffer is a protected method, so testLoad was created as a workaround

[yjbanov]

Ah, makes sense. Might be useful to leave a comment explaining this as it's not immediately obvious why this is necessary.

[alanwutang11]

will do.

[yjbanov]

This expectation doesn't seem to have an effect. AFAICT the decode function hasn't been used for anything at this point, so it couldn't have been called. Maybe it should go below testProvider.testLoad? (I'm actually not sure when it's expected to be called)

[alanwutang11]

Yea, on second thought, that check is not necessary. It might be fine to just check at the end if called has been flipped to true. decode should be called with the loadBuffer call made by testProvider.testLoad.

[yjbanov]