Vault Without Purchase PayPal

[KunJeongPark]

Summary of changes

• Change PaymentSource in demo app to allow SetUpToken creation for both card and PayPal
• Implement parent class VaultViewModel inherited by CardVaultViewModel and PayPalVaultViewModel to reuse common properties and views.
• Rename CardVaultState to VaultState to define all common properties, move payment specific properties as published properties in their respective view models
• Implement getting url from SetUpToken request
• Create UI for PayPal Vault without Purchase
• Implement vault(url:) function to launch ASWebSession
• Parse results fromASWebSession
• Define PayPalVaultDelegate protocol, methods. Add PayPalVaultDelegate protocol conformance to PayPalVaultViewModel and implement methods in PayPalVaultViewModel
• Update states for UI with vault method.
• Handle success, failure results from vault(url:) in SDK through PayPalWebCheckoutClient's vault delegate functions
• Merchant server side PaymentToken call and Demo app output
• Unit tests for vault(url:) function

https://github.com/paypal/paypal-ios/assets/9273272/496553c9-efd3-44fe-be0d-e699853c80a8

Checklist

• [x] Added a changelog entry

Authors

@KunJeongPark

[KunJeongPark]

I've been thinking about the approach to minimize the number of views in the demo app as suggested in previous PR's such as suggestion to use general view that toggles content for each API result and approach that I explored above, which was to use parent viewModel between two payment methods for vaulting without payment so that SetupTokenView and PaymentTokenView and their result views can be reused across different payment methods when applicable.

I considered other payment methods being added as stand alone vault features in this approach to reducing the number of views by having a parent VaultViewModel class with shared state and payment specific properties as published properties in their respective viewModels. In JS, so far we have PayPal and Card vaulting and in Braintree, we have PayPal, Card and Venmo vaulting if I remember correctly.

Assuming that purpose of our demo app is for internal testing, demonstration of features and giving example usage of SDK to merchants, I think simplicity might be the best approach.

We can adapt as we add more payment methods to vault. As far as I know, the flow for vault without pay is the same: create setupToken, do approval in SDK with payment method and merchants use this temporary setupToken to create paymentToken.