[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. ↩ ↩² ↩³

[stuartmorgan-g]

LGTM