Publicize: Fix Facebook auth success detection

[frosty]

Fixes #17794. The URL used to determine success for the Facebook Publicize connection flow has changed. This PR updates the check used to determine a Facebook success so that it matches the new URL (see final commit for those changes), as well as some slight refactoring to improve the existing code in this section.

The new URL should contain state and code values if it is a Facebook login, and state and error if it was unsuccessful. All other login types should be unaffected.

Please see the original issue for more detail about the problem.

To test

• Open the app and select a WP.com or Jetpack site.
• On the My Site screen, scroll down to the Configuration section.
• Tap "Sharing".
• Tap "Facebook".
• Tap "Connect".
• Login with a Facebook account that has at least one page.
• Accept all Facebook permissions.
• Ensure that the webview is dismissed and you are asked which account you would like to connect.

Also ensure that you can still connect some other account types such as Twitter.

Regression Notes

1. Potential unintended areas of impact

Other account types connecting, as I refactored some of that code slightly.

2. What I did to test those areas of impact (or what existing automated tests I relied on)

I manually tested connecting to other account types. I also ensured all tests pass, although I can't see that we have tests for publicize currently.

3. What automated tests I added (or what prevented me from doing so)

We could add some to check these various success and failure URLs, but I wanted to merge this soon and it would be a reasonable amount of work to compile a list of all of the various URLs we're checking for.

PR submission checklist:

• I have completed the Regression Notes.
• I have considered adding unit tests for my changes.
• I have considered adding accessibility improvements for my changes.
• I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

[peril-wordpress-mobile]

You can test the changes on this Pull Request by downloading it from AppCenter here with build number: 64472. IPA is available here. If you need access to this, you can ask a maintainer to add you.

[renanferrari]

@guarani I have some test accounts for Facebook and Twitter, so let me know if you need them 🙂

[peril-wordpress-mobile]

You can trigger optional UI/connected tests for these changes by visiting CircleCI here.

[guarani]

I tested Facebook, LinkedIn, and Twitter and all working great!

I left a minor code comment, but the change looks good to me

[guarani]

This is not a blocker, just a possible improvement.

The URL format I see is:

https://public-api.wordpress.com/connect/?code=VERY_LONG_RANDOM_STRING&state=VERY_LONG_RANDOM_STRING#_=_

I'm not sure if failure cases can also include these random strings (tokens). If they can, it seems possible (though somewhat unlikely) for theses tokens to sometimes contain the characters "code" and "state", causing a false positive here.

Perhaps looking for query params with the names "code" and "state" would work more reliably:

        if let queryItems = URLComponents(url: url, resolvingAgainstBaseURL: true)?.queryItems {
            let containsState = queryItems.contains(where: { queryItem in
                queryItem.name == AuthorizeURLComponents.state.rawValue
            })
            let containsCode = queryItems.contains(where: { queryItem in
                queryItem.name == AuthorizeURLComponents.code.rawValue
            })
            if containsState && containsCode {
                return .verify
            }
        }