Validate VPN errors before re-throwing them

[samsymons]

Please review the release process for BrowserServicesKit here.

Required:

Task/Issue URL: https://app.asana.com/0/414709148257752/1208225499545869/f
iOS PR: duckduckgo/iOS#3513
macOS PR: duckduckgo/macos-browser#3490
What kind of version bump will this require?: Major

Description:

This PR attempts to catch malformed errors before they get thrown to the OS. It also informs us when this happens.

Steps to test this PR:

To test this, we need to make sure that existing errors still throw as expected, and that errors we're trying to filter out get successfully caught.

For testing existing errors on iOS:

1. Open PacketTunnelProvider.swift
2. Go to func startTunnel(options: [String: NSObject]? = nil) async throws, which is the function where errors from the rest of the VPN get thrown to the OS
3. Pick one of the try functions in startTunnel, for example try await startTunnel(onDemand: startupOptions.startupMethod == .automaticOnDemand)
4. Inside that function, throw an error such as TunnelError.simulateTunnelFailureError
5. Now, attempt to start the VPN, and check that it fails
6. After it has failed, go to the iOS debug menu's Network Protection section, and check the metadata at the very bottom to confirm that the lastDisconnectError value to make sure it matches the error you used in step 4

For testing errors that we're filtering out:

First, add the following error somewhere in PacketTunnelProvider:

    enum ErrorThatCrashes: CustomNSError {
        case crash

        var errorCode: Int {
            return 123
        }

        static var errorDomain: String {
            return "error-domain"
        }

        var errorUserInfo: [String: Any] {
            return [
                NSUnderlyingErrorKey: "testing"
            ]
        }
    }

This error uses an underlying error that isn't a valid error object, which causes a VPN extension crash. Next:

1. Throw an instance of that error from the same place that you used in the first set of instructions
2. Check the Debug menu's Network Protection section and confirm that you see a valid error object in the metadata which is of the type InvalidDiagnosticError
3. Also, check that it contains an underlying error that is just domain and code

OS Testing:

• iOS 14
• iOS 15
• iOS 16
• macOS 10.15
• macOS 11
• macOS 12

---

Internal references:

Software Engineering Expectations
Technical Design Template

[samsymons]

We want to know what error violated the underlying error validation, but without actually including its underlying errors - knowing its domain and code should be enough to debug further.

[diegoreymendez]

Added a comment.