Update Networking layer with GET /wp-json/wc/v3/customers/<id>

[iamgabrielma]

Part of #7741

Description

For merchants to be able to see and choose existing customers from their store when creating or editing orders, we need to know who are these existing customers. At the moment we can only get partial customer data based on other API properties, like Orders.

This PR adds the initial networking layer that we need in order to fetch existing customers from a Store. We do so by performing a GET request to the /wp-json/wc/v3/customers/<id> API endpoint

Why don't we fetch the entirety of /customers/ endpoint?

We discovered that this endpoint does not search for first and last names, the proposed workaround is to use /wc-analytics/customers?search= instead, which returns the customer's ID, then use /customers/<id> to fetch the actual data.

For the moment, we're only modelling the Customer entity with a limited number of properties, the ones we actually use within the Order Creation screen (email, firstName, lastName, billing details, and shipping details), rather than all available properties. We can include more later as needed.

Changes

• Added CustomerRemote, CustomerMapper, and Customer objects to the Networking layer. This retrieves, decodes, maps, and models an individual Customer entity from its JSON representation received from the API.
• Modified Networking.generated and Models+Copiable.generated via rake generate, due adding GeneratedCopiable and GeneratedFakeable conformance to the model.
• Added a customer.json file replicating a dummy /wp-json/wc/v3/customers/<id> API response, so we can Unit Test without hitting the actual network.

To avoid this PR to become too big, I'll add further Unit Tests on a different one.

Testing instructions

• Make sure that Unit Tests pass

[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 pr7746-32dfe2a on your iPhone

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

[joshheald]

Looks good, a few suggestions for reducing the amount of test code.

[joshheald]

Why the default strings here, given it's an optional property? I think you'd be best off with one or the other: make the property non-optional, or make it nil when we don't have the name.

[iamgabrielma]

Oh that's right! firstName and lastName are not required by the API so initially I made them optional, that said, without the name we won't be able to perform a search later on. For now I'll leave them Optional for simplicity, but most likely we'll have to loop back and modify this when we implement the actual search, once we know better what we need. Removed default values at f5c1c3e

[joshheald]

You can remove these asserts at least, or even this whole test, as they are covered by the correctly_parsed test

[iamgabrielma]

Gotcha! Done at 2fe9688. I left the rest of the test so we can test the difference between if the data can be loaded from the local file vs if the values are correctly parsed. I see the correctly_parsed test also includes that the data must be loaded first in order to work, but it felt right to keep them separate. Happy to remove it entirely in any case 👍

[joshheald]

I think this assert is unnecessary: the previous one will fail and throw if it's nil. You may want to check another property about the customer instead, or nothing at all.

[iamgabrielma]

I see what you mean, done at 32dfe2a

[joshheald]

Sorry, I meant the XCTAssertNotNil is unnecessary, though you're right that the XCTAssert(result.isSuccess) is also tested by the XCTUnwrap.

To be honest, and on second thoughts, since you never use the customer other than checking that it's there, unwrapping it isn't needed, I would consider simply doing XCTAssertNotNil(result.get()) in place of all three, though perhaps with the unwrap it's clearer that we're looking at a customer.

This is super trivial, no need to change it, I'm only commenting again because I'd not been clear the first time.