Fix/remove dependency from debug sourceset

[JorgeMucientes]

Description

This PR removes the use of IAPShowcaseMobilePayAPIProvider in production code to fix release build compile issues. Instead, it adds new IapMobilePayApiProvider file available for release source sets that copies the code we had in IAPShowcaseMobilePayAPIProvider. This is enough for now, as IAP feature is still under development and we might refactor this code later on.

Keep in mind that In-App Purchases code is under a feature flag that only enables the feature for debug builds, so these are production safe changes.

Compiling the app for release using ./gradlew assembleVanillaRelease should be enough to check the problem is fixed.

Sorry for the trouble caused for generating the release.

[peril-woocommerce]

	Warnings
⚠️	PR is not assigned to a milestone.

Generated by 🚫 dangerJS

[ParaskP7]

👋 @JorgeMucientes !

First of all, thank you for dealing with this and unblocking the release process! 🥇

Question (❓): Since IAPShowcaseMobilePayAPIProvider and IapMobilePayApiProvider are actually 100% duplicate classes, do you maybe have any idea on how to make them more maintainable so that if in the future one of those classes gets updated, we could get some guarantee that the other one will also get to be updated (if need be).

I am just trying to figure out how we could avoid a potential future duplication related problem where an engineer will forget to update both? Maybe, even just a quick KDoc on top of each class class to point to the other one would be enough for now, not sure, wdyt? 🤔

[wpmobilebot]

You can test the changes on this Pull Request by downloading an installable build, or scanning this QR code:

[codecov-commenter]

Codecov Report

Base: 43.13% // Head: 43.10% // Decreases project coverage by -0.02% ⚠️

Coverage data is based on head (4562d46) compared to base (9144ea4).
Patch coverage: 0.00% of modified lines in pull request are covered.

❗ Current head 4562d46 differs from pull request most recent head 6bb0a7c. Consider uploading reports for the commit 6bb0a7c to get more accurate results

Additional details and impacted files

@@                Coverage Diff                 @@
##             release/11.8    #8147      +/-   ##
==================================================
- Coverage           43.13%   43.10%   -0.03%     
  Complexity           3484     3484              
==================================================
  Files                 683      684       +1     
  Lines               37161    37184      +23     
  Branches             4926     4933       +7     
==================================================
  Hits                16030    16030              
- Misses              19685    19708      +23     
  Partials             1446     1446              

Impacted Files	Coverage Δ
...login/storecreation/iap/IapMobilePayApiProvider.kt	0.00% <0.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[JorgeMucientes]

Thanks for the quick review @ParaskP7 🙏🏼

Yeah, this was more of a quick fix to unlock the release flow with the least changes possible. I agree that if the 2 classes are identical we should remove one of them and put the one we keep in the proper package. I'm not sure tough if we will need to customize the behaviour and thus, have different implementations of IAPMobilePayAPI interface for other flows where IAP is used. I'd like to double check with @kidinov how likely is this to happen.

[ParaskP7]

Yeah, this was more of a quick fix to unlock the release flow with the least changes possible. I agree that if the 2 classes are identical we should remove one of them and put the one we keep in the proper package. I'm not sure tough if we will need to customize the behaviour and thus, have different implementations of IAPMobilePayAPI interface for other flows where IAP is used. I'd like to double check with @kidinov how likely is this to happen.

Got it, thanks @JorgeMucientes ! 💯

Then maybe adding a quick KDoc for now will be enough, wdyt? 🤔

I would not be comfortable merging this without at least making the duplication explicit somehow (thus more visible). 😞

Maybe, even just a quick KDoc on top of each class class to point to the other one would be enough for now, not sure, wdyt? 🤔

[JorgeMucientes]

In the meantime I've created an issue to keep track of this duplication and avoid blocking this PR.

[ParaskP7]

LGTM! 💯