[webview_flutter] Adds support to respond to recoverable SSL certificate errors

[bparrishMines]

tl;dr This adds the NavigationDelegate.onSslAuthError method for recoverable SSL certificate errors.
Fixes flutter/flutter#36925

Important Note: This is a more niche feature that should only be used for logging errors or used in a development environment. See docs for WebViewClient.onReceviedSslError. Therefore, I included multiple comments throughout that highly recommends calling cancel() and ensured that we call or set cancel/performDefaultHandling when the method is not set with unit tests.

The respective platform callback methods are:
Android: WebViewClient.onReceviedSslError
iOS/macOS: WKNavigationDelegate(_:didReceive:completionHandler:)

The Android method is only called for recoverable SSL errors while the iOS/macOS method is called for all authentication related callbacks. So for iOS/macOS, the callback is only implemented when:

1. URLAuthenticationChallenge.protectionSpace.authenticationMethod == NSURLAuthenticationMethodServerTrust
2. SecTrustEvaluateWithError() returns false when passed URLAuthenticationChallenge.protectionSpace.serverTrust.
3. SecTrustGetTrustResult() returns SecTrustResultType.recoverableTrustFailure when passed URLAuthenticationChallenge.protectionSpace.serverTrust.

This implementation only really provides the error description, certificate data, and the ability to proceed or cancel. Providing access to verify or manipulate a certificate seem to be outside the scope of a WebView plugin since Android and iOS/macOS have an extensive separate library for them.

Providing the encoded data for the X509Certificate should be enough to use the certificate with another library.

A few platform differences to note:

1. Android provides a String getUrl() for the error while iOS/macOS provides a URLProtectionSpace that provides host, port, protocol, and proxyType. I didn't think I would be able to create a full Dart Uri for iOS/macOS from these reliably, so each platform provides these values separately.
2. A certificate can have multiple errors, but only Android provides access to them. However, both platforms say that they provide access to the "primary" error, so I just provided that. A platform specific value for Android could be added later.

Side note: Android provides a WebViewClient.onReceivedClientCertRequest to read all certificate requests that don't get a recoverable error. A separate plugin method could be made to receive these.

Side Side note:
Old PR: flutter/plugins#2285
Fixes flutter/flutter#74609
Old quote about this feature from flutter/plugins#2285 (comment):

By default, Flutter plugins should expect or enforce a secure environment, therefore we can not process this PR as-is. However, I can see a use case, especially during local development when it's just may not be feasible to have a properly signed https connection.

Pre-Review Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter.
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to 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, or I have commented below to indicate which version change exemption this PR falls under¹.
• I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style, or I have commented below to indicate which CHANGELOG exemption this PR falls under¹.
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented below to indicate which test exemption this PR falls under¹.
• All existing and new tests are passing.

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

Footnotes

1. Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩² ↩³

[bparrishMines]

@stuartmorgan-g I changed this back to return an AuthenticationChallengeResponse. Alternatively, I added async constructors for AuthenticationChallengeResponse and URLCredential. Ideally this solution should still prevent flutter/flutter#162437.

If it doesn't, then that would prove that the issue isn't caused by a race condition because the object has to be added to the native InstanceManager first before the async constructor returns.

[stuartmorgan-g]

Some minor comment suggestions, but looks good to split up.

[stuartmorgan-g]

I think here and below we should state what the intended use case is, since currently it sounds like we have this whole feature but are telling people never to use it. How about adding one more sentence here: "[proceed] should generally only be used in test environments, as using it in production can expose users to security and privacy risks."

[stuartmorgan-g]

And then here maybe change this to: "Warning: Calling [proceed] in a production environment is strongly discouraged, as an invalid SSL certificate means that the connection is not secure, so proceeding can expose users to security and privacy risks."

[stuartmorgan-g]

Same wording note here.

[stuartmorgan-g]

Just to make sure I'm understanding the flow here, all of these breaks are because that way we fall through to the final UrlSessionAuthChallengeDisposition.performDefaultHandling call and that will cancel?