Rename PointOfSaleProductService to PointOfSaleItemService with basic unit tests on variations

[jaclync]

Part of #14702

Description

As we're adding variation items fetching to PointOfSaleItemServiceProtocol, it starts to look odd with the name PointOfSaleProductService that seems to be product-specific. This PR simply renames PointOfSaleProductService to PointOfSaleItemService across different files and references. Two test cases were also added for providePointOfSaleVariationItems function that didn't fit in #14786 that introduced it.

Renaming and Refactoring:

• WooCommerce/Classes/ViewRelated/Hub Menu/HubMenuViewModel.swift: Updated the instantiation of the PointOfSaleItemService to reflect the new name.

• Yosemite/Yosemite/PointOfSale/PointOfSaleItemService.swift: Renamed the class PointOfSaleProductService to PointOfSaleItemService and updated internal references accordingly. [1] [2]

• Yosemite/YosemiteTests/PointOfSale/PointOfSaleItemServiceTests.swift: Updated the test class name and references from PointOfSaleProductServiceTests to PointOfSaleItemServiceTests, and added new test cases for variations. [1] [2] [3] [4] [5]

Steps to reproduce

A confidence test to ensure the products & variations are loaded properly in the item selector would be helpful.

Testing information

• @jaclync performs a confidence test above before merging

Screenshots

---

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

Reviewer (or Author, in the case of optional code reviews):

Please make sure these conditions are met before approving the PR, or request changes if the PR needs improvement:

• The PR is small and has a clear, single focus, or a valid explanation is provided in the description. If needed, please request to split it into smaller PRs.
• Ensure Adequate Unit Test Coverage: The changes are reasonably covered by unit tests or an explanation is provided in the PR description.
• Manual Testing: The author listed all the tests they ran, including smoke tests when needed (e.g., for refactorings). The reviewer confirmed that the PR works as expected on all devices (phone/tablet) and no regressions are added.

[wpmobilebot]

📲 You can test the changes from this Pull Request in WooCommerce iOS by scanning the QR code below to install the corresponding build.

	App Name	WooCommerce iOS
	Build Number	pr14793-346e6c1
	Version	21.3
	Bundle ID	com.automattic.alpha.woocommerce
	Commit	346e6c1
	App Center Build	WooCommerce - Prototype Builds #12372

Automatticians: You can use our internal self-serve MC tool to give yourself access to App Center if needed.

[iamgabrielma]

LGTM! 🚢

[joshheald]

LGTM, but threw up some future questions for our overall approach.

It makes sense if we have a single service for fetching both types of items. I think this is forced on us by the reliance on server pagination.

However, setting pagination aside, different item types that make up the ItemListState would only need to be combined in the PointOfSaleItemsController. The request for variations lists is different for the one for product lists.

In future, if we have custom grids or add in other types of items (e.g. shipping, discounts, coupons, customers), we'd probably want to have other services to provide each of these.

Unless we have a single endpoint for all POS items (perhaps this would be a good idea) we may not want to combine them all at the service level. Pagination will definitely be a sticking point for this!

[jaclync]

It makes sense if we have a single service for fetching both types of items. I think this is forced on us by the reliance on server pagination.

However, setting pagination aside, different item types that make up the ItemListState would only need to be combined in the PointOfSaleItemsController. The request for variations lists is different for the one for product lists.

In future, if we have custom grids or add in other types of items (e.g. shipping, discounts, coupons, customers), we'd probably want to have other services to provide each of these.

Unless we have a single endpoint for all POS items (perhaps this would be a good idea) we may not want to combine them all at the service level. Pagination will definitely be a sticking point for this!

Yea good question, was the original plan to have different services like PointOfSaleProductService, PointOfSaleVariationService (and similar for other item types) in the items controller? If so, the variation service might have to take in the parent product dependency from the initializer or some separate function/property setter. I can work on this change after the confirmation.