[Payments] Refactor into PaymentRequestState and Spec

[Payments] Refactor into PaymentRequestState and Spec

The result is more unit-testable.

PaymentRequestState will contain everything about the user's state in
the flow: what their selections are, and whether they are ready to pay.

PaymentRequestSpec will contain everything about the merchant
specification: are they requesting shipping info, payer's info, or what
are their supported forms of payments.

A further CL will attempt to remove the view controller's dependence on 
PaymentRequest and rather just pass the state and the spec pointers.

BUG=701345
TEST=browser_tests, components_unittests

Review-Url: https://codereview.chromium.org/2742813004
Cr-Commit-Position: refs/heads/master@{#457054}
Committed: https://chromium.googlesource.com/chromium/src/+/f1a7a37514b2eda7e895b0e52d120e937d58b385

[Mathieu, 2017-03-10 22:13:06]

The CQ bit was checked by mathp@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-10 22:13:35]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-10 22:16:45]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-10 22:16:45]

Dry run: Try jobs failed on following builders:
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-device-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device-xcode-...)
  ios-simulator-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-xco...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Mathieu, 2017-03-14 01:41:12]

Patchset #1 (id:1) has been deleted

[Mathieu, 2017-03-14 01:41:17]

Patchset #1 (id:20001) has been deleted

[Mathieu, 2017-03-14 01:41:32]

The CQ bit was checked by mathp@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-14 01:42:15]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-14 01:50:21]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-14 01:50:22]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Mathieu, 2017-03-14 12:09:33]

The CQ bit was checked by mathp@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-14 12:09:49]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-14 12:16:47]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-14 12:16:48]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Mathieu, 2017-03-14 14:03:50]

Description was changed from

==========
[Payments] Refactor into PaymentRequestState and Spec

BUG=
==========

to

==========
[Payments] Refactor into PaymentRequestState and Spec

The result is more unit-testable.

PaymentRequestState will contain everything about the user's state in the flow:
what their selections are, and whether they are ready to pay.

PaymentRequestSpec will contain everything about the merchant specification: are
they requesting shipping info, payer's info, or what are their supported forms
of payments.


BUG=701345
==========

[Mathieu, 2017-03-14 14:03:50]

mathp@chromium.org changed reviewers:
+ anthonyvd@chromium.org, rouslan@chromium.org

[Mathieu, 2017-03-14 14:04:00]

Patchset #3 (id:80001) has been deleted

[Mathieu, 2017-03-14 14:04:04]

The CQ bit was checked by mathp@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-14 14:04:23]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Mathieu, 2017-03-14 14:04:53]

Hi you two. This is not a functional change, but it has a big surface so I'm
sending it early. I'm still writing unittests for PaymentRequestState, but would
love if you could take a look now.

[Mathieu, 2017-03-14 14:05:41]

Description was changed from

==========
[Payments] Refactor into PaymentRequestState and Spec

The result is more unit-testable.

PaymentRequestState will contain everything about the user's state in the flow:
what their selections are, and whether they are ready to pay.

PaymentRequestSpec will contain everything about the merchant specification: are
they requesting shipping info, payer's info, or what are their supported forms
of payments.


BUG=701345
==========

to

==========
[Payments] Refactor into PaymentRequestState and Spec

The result is more unit-testable.

PaymentRequestState will contain everything about the user's state in the flow:
what their selections are, and whether they are ready to pay.

PaymentRequestSpec will contain everything about the merchant specification: are
they requesting shipping info, payer's info, or what are their supported forms
of payments.

A further CL will attempt to remove the view controller's dependence on
PaymentRequest and rather just pass the state and the spec pointers.

BUG=701345
TEST=browser_tests, components_unittests
==========

[commit-bot: I haz the power, 2017-03-14 15:02:38]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-14 15:02:39]

Dry run: This issue passed the CQ dry run.

[Mathieu, 2017-03-14 15:34:37]

The CQ bit was checked by mathp@chromium.org to run a CQ dry run

[Mathieu, 2017-03-14 15:35:06]

Hi, I added some unittests for PaymentRequestState.

can you PTAL for realz? Thanks

[commit-bot: I haz the power, 2017-03-14 15:35:22]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-14 15:39:48]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-14 15:39:49]

Dry run: Try jobs failed on following builders:
  android_compile_dbg on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)
  android_cronet on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_cron...)
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_tsan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Mathieu, 2017-03-14 15:46:34]

The CQ bit was checked by mathp@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-14 15:47:15]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[tmartino, 2017-03-14 16:02:12]

On 2017/03/14 at 15:35:06, mathp wrote:
> Hi, I added some unittests for PaymentRequestState.
> 
> can you PTAL for realz? Thanks

I think the general model makes sense. It's good to separate out the
merchant-provided information, and it helps my mental model to organize the
difference between the mutable and immutable state this way.

There are now a lot of classes with somewhat nuanced interactions between them,
and it's not super easy to interpret those from the code. It would be good to
add some top-level documentation to payment_request.h and payment_request_spec.h
explaining what these classes are, how they are meant to relate to each other,
and where they should be used. The various observers and delegates might also
benefit from some explaining.

[please use gerrit instead, 2017-03-14 16:05:18]

While I'm reviewing, can you make the description lines at most 72 chars long,
please? Thank you!

[please use gerrit instead, 2017-03-14 16:35:22]

So wonderful to see all these tests! :-)

https://codereview.chromium.org/2742813004/diff/140001/components/payments/co...
File components/payments/content/payment_request.h (right):

https://codereview.chromium.org/2742813004/diff/140001/components/payments/co...
components/payments/content/payment_request.h:142:
std::vector<std::unique_ptr<autofill::AutofillProfile>> profile_cache_;
Should these be moved to state_?

https://codereview.chromium.org/2742813004/diff/140001/components/payments/co...
File components/payments/content/payment_request_spec.h (right):

https://codereview.chromium.org/2742813004/diff/140001/components/payments/co...
components/payments/content/payment_request_spec.h:17: class PaymentRequestSpec
{
Please add a comment for the purpose of this class.

https://codereview.chromium.org/2742813004/diff/140001/components/payments/co...
components/payments/content/payment_request_spec.h:47: mojom::PaymentDetails*
details() { return details_.get(); }
From what I understand, details() and options() should be read-only, so let's
try to use const-ref for return parameter and make the method const as well.

https://codereview.chromium.org/2742813004/diff/140001/components/payments/co...
File components/payments/content/payment_request_state.h (right):

https://codereview.chromium.org/2742813004/diff/140001/components/payments/co...
components/payments/content/payment_request_state.h:122: PaymentRequestSpec*
spec_;
// Not owned. Never null. Outlives this object.

https://codereview.chromium.org/2742813004/diff/140001/components/payments/co...
components/payments/content/payment_request_state.h:128: // This is owned by
|details_|, which is owned by this object and lives until
Please update the comment. |details_| is in |spec_| now.

[anthonyvd, 2017-03-14 16:46:41]

https://codereview.chromium.org/2742813004/diff/120001/components/payments/co...
File components/payments/content/payment_request.h (right):

https://codereview.chromium.org/2742813004/diff/120001/components/payments/co...
components/payments/content/payment_request.h:92: // Uses CurrencyFormatter to
get the formatted currency code for this
This and the following 5 functions will also have to be moved if we're going to
remove dependencies on PaymentRequest in the view controllers. Where do you see
them going? spec, state, somewhere else?

https://codereview.chromium.org/2742813004/diff/120001/components/payments/co...
components/payments/content/payment_request.h:136:
std::unique_ptr<PaymentRequestSpec> spec_;
unique_ptr because they have to be initialized in Init rather than the ctor,
correct?

https://codereview.chromium.org/2742813004/diff/120001/components/payments/co...
File components/payments/content/payment_request_state.h (right):

https://codereview.chromium.org/2742813004/diff/120001/components/payments/co...
components/payments/content/payment_request_state.h:40: virtual const
std::string& GetApplicationLocale() = 0;
Spec will also probably need the Locale, can we just pass it to both the ctors?

[commit-bot: I haz the power, 2017-03-14 16:55:08]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-14 16:55:09]

Dry run: This issue passed the CQ dry run.

[Mathieu, 2017-03-14 17:14:22]

Description was changed from

==========
[Payments] Refactor into PaymentRequestState and Spec

The result is more unit-testable.

PaymentRequestState will contain everything about the user's state in the flow:
what their selections are, and whether they are ready to pay.

PaymentRequestSpec will contain everything about the merchant specification: are
they requesting shipping info, payer's info, or what are their supported forms
of payments.

A further CL will attempt to remove the view controller's dependence on
PaymentRequest and rather just pass the state and the spec pointers.

BUG=701345
TEST=browser_tests, components_unittests
==========

to

==========
[Payments] Refactor into PaymentRequestState and Spec

The result is more unit-testable.

PaymentRequestState will contain everything about the user's state in
the flow: what their selections are, and whether they are ready to pay.

PaymentRequestSpec will contain everything about the merchant
specification: are they requesting shipping info, payer's info, or what
are their supported forms of payments.

A further CL will attempt to remove the view controller's dependence on 
PaymentRequest and rather just pass the state and the spec pointers.

BUG=701345
TEST=browser_tests, components_unittests
==========

[Mathieu, 2017-03-14 18:04:58]

The CQ bit was checked by mathp@chromium.org to run a CQ dry run

[Mathieu, 2017-03-14 18:05:39]

Hi, I think everything is addressed. PTAL?

https://codereview.chromium.org/2742813004/diff/120001/components/payments/co...
File components/payments/content/payment_request.h (right):

https://codereview.chromium.org/2742813004/diff/120001/components/payments/co...
components/payments/content/payment_request.h:92: // Uses CurrencyFormatter to
get the formatted currency code for this
On 2017/03/14 16:46:41, anthonyvd wrote:
> This and the following 5 functions will also have to be moved if we're going
to
> remove dependencies on PaymentRequest in the view controllers. Where do you
see
> them going? spec, state, somewhere else?

Moved some to state, the currency formatter I don't really know where to fit it.
Will have to think about it!

https://codereview.chromium.org/2742813004/diff/120001/components/payments/co...
components/payments/content/payment_request.h:136:
std::unique_ptr<PaymentRequestSpec> spec_;
On 2017/03/14 16:46:41, anthonyvd wrote:
> unique_ptr because they have to be initialized in Init rather than the ctor,
> correct?

Yes

https://codereview.chromium.org/2742813004/diff/120001/components/payments/co...
File components/payments/content/payment_request_state.h (right):

https://codereview.chromium.org/2742813004/diff/120001/components/payments/co...
components/payments/content/payment_request_state.h:40: virtual const
std::string& GetApplicationLocale() = 0;
On 2017/03/14 16:46:41, anthonyvd wrote:
> Spec will also probably need the Locale, can we just pass it to both the
ctors?

I don't think spec will need the locale... perhaps we can re-evaluate if it
does?

https://codereview.chromium.org/2742813004/diff/140001/components/payments/co...
File components/payments/content/payment_request.h (right):

https://codereview.chromium.org/2742813004/diff/140001/components/payments/co...
components/payments/content/payment_request.h:142:
std::vector<std::unique_ptr<autofill::AutofillProfile>> profile_cache_;
On 2017/03/14 16:35:21, ಠ_ಠ wrote:
> Should these be moved to state_?

OK. Was trying not to conflate the state and the list of profiles, but it's true
that they belong in State more than here.

https://codereview.chromium.org/2742813004/diff/140001/components/payments/co...
File components/payments/content/payment_request_spec.h (right):

https://codereview.chromium.org/2742813004/diff/140001/components/payments/co...
components/payments/content/payment_request_spec.h:17: class PaymentRequestSpec
{
On 2017/03/14 16:35:21, ಠ_ಠ wrote:
> Please add a comment for the purpose of this class.

Done.

https://codereview.chromium.org/2742813004/diff/140001/components/payments/co...
components/payments/content/payment_request_spec.h:47: mojom::PaymentDetails*
details() { return details_.get(); }
On 2017/03/14 16:35:21, ಠ_ಠ wrote:
> From what I understand, details() and options() should be read-only, so let's
> try to use const-ref for return parameter and make the method const as well.

Done.

https://codereview.chromium.org/2742813004/diff/140001/components/payments/co...
File components/payments/content/payment_request_state.h (right):

https://codereview.chromium.org/2742813004/diff/140001/components/payments/co...
components/payments/content/payment_request_state.h:122: PaymentRequestSpec*
spec_;
On 2017/03/14 16:35:21, ಠ_ಠ wrote:
> // Not owned. Never null. Outlives this object.

Done.

https://codereview.chromium.org/2742813004/diff/140001/components/payments/co...
components/payments/content/payment_request_state.h:128: // This is owned by
|details_|, which is owned by this object and lives until
On 2017/03/14 16:35:21, ಠ_ಠ wrote:
> Please update the comment. |details_| is in |spec_| now.

Done.

[commit-bot: I haz the power, 2017-03-14 18:05:49]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[please use gerrit instead, 2017-03-14 18:07:15]

lgtm

[anthonyvd, 2017-03-14 18:11:24]

lgtm

https://codereview.chromium.org/2742813004/diff/120001/components/payments/co...
File components/payments/content/payment_request_state.h (right):

https://codereview.chromium.org/2742813004/diff/120001/components/payments/co...
components/payments/content/payment_request_state.h:40: virtual const
std::string& GetApplicationLocale() = 0;
On 2017/03/14 at 18:05:39, Mathieu Perreault wrote:
> On 2017/03/14 16:46:41, anthonyvd wrote:
> > Spec will also probably need the Locale, can we just pass it to both the
ctors?
> 
> I don't think spec will need the locale... perhaps we can re-evaluate if it
does?

I'm thinking of the shipping options provided by the website, for which we need
the locale to format the amount value. In any case, classes that use state and
spec need the locale, so they either need to get this delegate or call a
GetApplicationLocale function that just forwards the call to this one here. At
this point, might as well just pass locale to state's ctor (unless I'm missing
something and locale can change at runtime).

Not a big deal, I won't lose sleep if you feel strongly enough to leave it as-is
:)

[commit-bot: I haz the power, 2017-03-14 18:54:15]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-14 18:54:17]

Dry run: Try jobs failed on following builders:
  android_n5x_swarming_rel on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_...)

[Mathieu, 2017-03-15 00:55:56]

The CQ bit was checked by mathp@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-15 00:56:36]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-15 01:00:40]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-15 01:00:41]

Dry run: Try jobs failed on following builders:
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-device-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device-xcode-...)
  ios-simulator-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-xco...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Mathieu, 2017-03-15 01:36:23]

The CQ bit was checked by mathp@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-15 01:37:09]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Mathieu, 2017-03-15 01:37:53]

Patchset #7 (id:180001) has been deleted

[commit-bot: I haz the power, 2017-03-15 01:39:51]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-15 01:39:52]

Dry run: Try jobs failed on following builders:
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-device-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device-xcode-...)
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)

[Mathieu, 2017-03-15 01:57:02]

The CQ bit was checked by mathp@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-15 01:57:49]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Mathieu, 2017-03-15 02:11:32]

Patchset #8 (id:220001) has been deleted

[Mathieu, 2017-03-15 02:11:38]

The CQ bit was checked by mathp@chromium.org

[Mathieu, 2017-03-15 02:11:39]

The patchset sent to the CQ was uploaded after l-g-t-m from
rouslan@chromium.org, anthonyvd@chromium.org
Link to the patchset: https://codereview.chromium.org/2742813004/#ps240001
(title: "don't stop rebasin'")

[commit-bot: I haz the power, 2017-03-15 02:12:14]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Mathieu, 2017-03-15 02:51:14]

Thanks for the review!

https://codereview.chromium.org/2742813004/diff/120001/components/payments/co...
File components/payments/content/payment_request_state.h (right):

https://codereview.chromium.org/2742813004/diff/120001/components/payments/co...
components/payments/content/payment_request_state.h:40: virtual const
std::string& GetApplicationLocale() = 0;
On 2017/03/14 18:11:24, anthonyvd wrote:
> On 2017/03/14 at 18:05:39, Mathieu Perreault wrote:
> > On 2017/03/14 16:46:41, anthonyvd wrote:
> > > Spec will also probably need the Locale, can we just pass it to both the
> ctors?
> > 
> > I don't think spec will need the locale... perhaps we can re-evaluate if it
> does?
> 
> I'm thinking of the shipping options provided by the website, for which we
need
> the locale to format the amount value. In any case, classes that use state and
> spec need the locale, so they either need to get this delegate or call a
> GetApplicationLocale function that just forwards the call to this one here. At
> this point, might as well just pass locale to state's ctor (unless I'm missing
> something and locale can change at runtime).
> 
> Not a big deal, I won't lose sleep if you feel strongly enough to leave it
as-is
> :)

You're right, I think I'll probably move the CurrencyFormatter somewhere (state
or spec or helper?) and provide the locale to that object at construction time
(since PaymentRequest has it).

[commit-bot: I haz the power, 2017-03-15 03:43:12]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-15 03:43:13]

Try jobs failed on following builders:
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Mathieu, 2017-03-15 10:47:10]

The CQ bit was checked by mathp@chromium.org

[commit-bot: I haz the power, 2017-03-15 10:47:23]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-15 11:23:41]

CQ is committing da patch.

Bot data: {"patchset_id": 240001, "attempt_start_ts": 1489574830432080,
"parent_rev": "adecbfa48d6fec7f33e2ff2fc4634547c9573156", "commit_rev":
"f1a7a37514b2eda7e895b0e52d120e937d58b385"}

[commit-bot: I haz the power, 2017-03-15 11:24:24]

Description was changed from

==========
[Payments] Refactor into PaymentRequestState and Spec

The result is more unit-testable.

PaymentRequestState will contain everything about the user's state in
the flow: what their selections are, and whether they are ready to pay.

PaymentRequestSpec will contain everything about the merchant
specification: are they requesting shipping info, payer's info, or what
are their supported forms of payments.

A further CL will attempt to remove the view controller's dependence on 
PaymentRequest and rather just pass the state and the spec pointers.

BUG=701345
TEST=browser_tests, components_unittests
==========

to

==========
[Payments] Refactor into PaymentRequestState and Spec

The result is more unit-testable.

PaymentRequestState will contain everything about the user's state in
the flow: what their selections are, and whether they are ready to pay.

PaymentRequestSpec will contain everything about the merchant
specification: are they requesting shipping info, payer's info, or what
are their supported forms of payments.

A further CL will attempt to remove the view controller's dependence on 
PaymentRequest and rather just pass the state and the spec pointers.

BUG=701345
TEST=browser_tests, components_unittests

Review-Url: https://codereview.chromium.org/2742813004
Cr-Commit-Position: refs/heads/master@{#457054}
Committed:
https://chromium.googlesource.com/chromium/src/+/f1a7a37514b2eda7e895b0e52d12...
==========

[commit-bot: I haz the power, 2017-03-15 11:24:26]

Committed patchset #8 (id:240001) as
https://chromium.googlesource.com/chromium/src/+/f1a7a37514b2eda7e895b0e52d12...