[Gutenberg] Fix gutenberg web-view auth issues with Atomic sites

[etoledom]

Fixes parts of wordpress-mobile/gutenberg-mobile#2358

This PR overrides RequestAuthenticator for the specific Gutenberg web view use case, where we want to use the regular auth type also for Atomic sites.

To test:

• Setup an atomic site and test as public and private.
• Create a post with a block not yet supported on mobile.
• Test on a real device.
• Will need Metro server running (on gutenberg-mobile develop branch is enough)
• Log out from your wp account in the app to clean cookies.
• Uninstall the app from your device.
• Install building the app from this PR.
• Login and go directly to the Atomic site.
• Open the created post with unsupported block.
• Open the unsupported block on the web view.
• Check that gutenberg opens on the web view without asking for credentials 🙏

@guarani can I ask you for a review? Thanks!

Also cc @marecar3 @aerych

PR submission checklist:

• I have considered adding unit tests where possible.
• 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 trigger an installable build for these changes by visiting CircleCI here.

[peril-wordpress-mobile]

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

[guarani]

Great work @etoledom! Everything is working as expected.

---

I followed the test steps above. Before running each of the following scenarios, I delete the existing WP app from my phone and clear Safari data (Settings | Safari | Clear History and Website Data) just to be sure I'm starting from a clean slate.

1. Brand new Atomic site, not yet launched, unsupported blocks in a draft post
   • First attempt resulted in a blank web view, no loading indicator was shown. Safari inspector couldn't find a web page to inspect. Second attempt worked fine.
2. Same Atomic site, now launched (public), using the same post (now published instead of draft)
3. Regular WP.com site, not yet launched, unsupported blocks in a draft post
4. Regular WP.com site, now launched (public), using the same post (now published instead of draft)

Sites used:

• Atomic site: pschrottkyunsupportedblockatomic.wpcomstaging.com
• Regular site: pschrottkyunsupportedblock.wordpress.com

The temporary issue in the first test scenario case may have been a network issue, I'm not sure. I went back and retested a couple of times and didn't see the issue again.

[etoledom]

Thank you !