[In-app Purchases] Improve transaction handling logic

[koke]

Closes: #8121

Description

This PR intends to improve some of the transaction handling logic:

• First, by pausing the transaction listener while making a purchase, so the purchase logic gets to create the order first. I've observed that sometimes there were race conditions where the transaction update got there first and the purchase failed because it was trying to create a duplicate order. This is a bit random and hard to reproduce though.
• Then, even if we re-send a transaction, if the backend returns a product_purchased error, it means that we have already sent that transaction before and there's an order for it. So now we treat this case as a success instead of a failure

Testing instructions

1. Go to Hub menu > IAP Debug
2. Purchase a new subscription
3. Notice the Pausing transaction listener and Resuming transaction listener messages in the console while the purchase is happening
4. Try to purchase the same product again. iOS will tell you that you already own that, but after dismissing the dialog, it returns a transaction and the app tries to submit that
5. Notice the Sending transaction to API message in the console followed by Existing order found for transaction ##### on site #####, ignoring. The app should show no alert with an error (unless the API call failed for another reason)

---

• 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 pr8124-d3945c7 on your iPhone

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

[toupper]

Code looks good and tests well, just a small question there.

[toupper]

With this approach it can happen that we handle the same transaction twice right, sending a duplicated order? Even if the backend ignores duplicated requests, it would be nice to prevent sending the same requests twice.

[koke]

I think that is fine. Since we aren't using the App Store Server API v2 yet, we aren't really sending "a transaction" to the API. We send the app receipt, which might not have even changed between requests, and use Apple's verifyReceipt endpoint response to get the list of transactions.

I think dealing with potential duplicate requests is something we need to live with, and this PR doesn't change that. It only ensures that if a duplicate transaction happens, it happens in the right order.

[toupper]

Thanks for your answer @koke. It's a pity that we cannot prevent at the moment sending duplicate requests in a simple way for now, but we can live with that.

[toupper]

Looks good to me and tests well, only that comment that we talked about. Thanks for this @koke! Now the whole implementation is much more robust 🎉