[REST API] Merge WordPressOrgRequest into RESTRequest

[selanthiraiyan]

Closes: #8512

Description

WordPressOrgRequest and RESTRequest have similar properties. For clarity we decided to merge them both and use
RESTRequest.

Testing instructions

• We need to test the areas in which WordPressOrgRequest (deleted in this PR) and RESTRequest are being used.
• Create a test store using JN. (without Jetpack)

Jetpack installation

• Log out of the app or skip login onboarding if needed.
• On the prologue screen, select "Log In" or "Continue with WordPress.com" based on the A/B test variant you get.
• Log in with your WordPress.com account.
• If your account doesn't have any associated site, notice that the empty store picker is displayed with the matching design as on Figma.
• Select Add a Store > Connect an existing site.
• Enter the address of your test store and tap Continue.
• You should see a Jetpack error screen from where you can Install Jetpack or Connect Jetpack natively.
• Validate that the Jetpack installation/setup works as before.

Application password

1. Turn on the applicationPasswordAuthenticationForSiteCredentialLogin feature flag.
2. Login into the app using .org site credentials.
3. Navigate to the coupons tab.
4. Try creating, editing and deleting coupons.
5. All features in the coupons screen should work as before.

Screenshots

NA

---

• I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

[wpmobilebot]

You can test the changes from this Pull Request by:

• Clicking here or scanning the QR code below to access App Center
• Then installing the build number pr8553-5b9705b on your iPhone

If you need access to App Center, please ask a maintainer to add you.

[itsmeichigo]

LGTM, I left a question regarding the tests.

[itsmeichigo]

I don't understand this test case, should the request parse the error though?

[selanthiraiyan]

The original test case validated that WordPressApiValidator is used in WordPressOrgRequest.

In RESTRequest we decided to use PlaceholderDataValidator which will not validate the request. So, I updated the test case to check that no errors are parsed.
i.e. test_wordpress_org_request_does_not_parse_wordpress_api_error and test_wordpress_org_request_does_not_parse_dotcom_error will ensure that PlaceholderDataValidator is used.

[itsmeichigo]

Should we check that result is failure because we are mocking a timeout error?

[selanthiraiyan]

I followed this pattern from the test_wordpress_org_request_does_not_parse_dotcom_error method.

The idea here is ensure try await remote.enqueue(request, mapper: mapper) doesn't throw any error.

Please note that the result is of type Data from DummyMapper, and not of Swift.Result<Data, Error> type.

[selanthiraiyan]

Thank you for the review, Huong! 🙇

I am going ahead and merging this now. I will make changes to the unit tests if anything comes up from our PR review discussions.