[webview_flutter] Add platform interface method loadRequest.

[BeMacized]

This PR is a partial resubmission of my colleague's PR: #4169.

It adds the loadRequest method to the webview plugin's platform interface, in order to support executing more specific requests when loading web pages.

Related issue:

• WebView for Flutter - Allow the POST of data on initial URL (instead of a GET) flutter#27730

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 [relevant style guides] and ran [the auto-formatter]. (Note that unlike the flutter/flutter repo, the flutter/plugins repo does use dart format.)
• I signed the [CLA].
• The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
• I listed at least one issue that this PR fixes in the description above.
• I updated pubspec.yaml with an appropriate new version according to the [pub versioning philosophy].
• I updated CHANGELOG.md to add a description of the change.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test exempt.
• All existing and new tests are passing.

[google-cla]

All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter.

We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only @googlebot I consent. in this pull request.

Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

[ydag]

@googlebot I consent.

[stuartmorgan]

LGTM with nit

[stuartmorgan]

Please add a second test that sets the optional parameters and ensures they come through as expected as well.

[BeMacized]

@stuartmorgan Would that not just be testing WebViewRequest's toJson method? We can of course add a second test, but as that toJson is already being tested here, including the optional parameters, I feel like we would be testing for the same thing twice.

[stuartmorgan]

How do you know that loadRequest calls WebViewRequest's toJson method? Or to be more precise: how do you know that it will continue to do so?

I guarantee you that I could write a PR that breaks the test I am asking you to write without changing WebViewRequest.toJson.

[BeMacized]

That is indeed a fair point, I now see it wouldn't. I've added the test for the optional parameters.

Just for my own curiosity: Would it not be possible to avoid testing toJson by instead mocking the WebViewRequest and checking if the return value of toJson gets passed to invokeMethod?

[stuartmorgan]

Tests should assert the behavior you want to guarantee. Which is a better description of the thing you want to guarantee is true:

1. "The method channel is sent the following specific keys with the expected values", or
2. "The call to the method channel is implemented by calling toJson on invokeMethod"?

(As an example of why only one of these is a good description: if someone later decides that the JSON keys aren't very descriptive, and sends a PR that updates toJson and its test to use different keys, what do you want to happen?)