PaymentApp: Introduce PaymentAppDatabase class.

PaymentApp: Introduce PaymentAppDatabase class.

Write PaymentAppDatabase class and then just move most of logics to access
database from PaymentAppManager to the new class.

The class is providing APIs to read/write payment app related data(e.g. manifest
and associated service worker). It can be shared between payment_app_manager.cc
and payment_app_context.cc.

The payment_app_manager.cc contains a actual implementation of the
PaymentAppManager interface[1] used on the page or worker.
Also, the payment_app_context.cc can be used to query all manifests data.
in order to update payment request UI in Chrome layer.

[1] https://w3c.github.io/webpayments-payment-apps-api/#payment-app-manager

BUG=661608
Committed: https://crrev.com/ab43057199ce68c2e9264fa98c9bd24cc1be4fd8
Cr-Commit-Position: refs/heads/master@{#439100}

[zino, 2016-12-14 17:03:42]

Description was changed from

==========
PaymentApp: Introduce PaymentAppDatabase class.

Write PaymentAppDatabase class and then just move most of logics to access
database from PaymentAppManager to the new class.

The class is providing APIs to read/write payment app related data(e.g. manifest
and associated service worker). It can be shared between payment_app_manager.cc
and payment_app_context.cc.

The payment_app_manager.cc contains a actual implementation of the
PaymentAppManager interface[1] used on the page or worker.
Also, the payment_app_context.cc can be used to query all manifests data[2]
in order to update payment request UI in Chrome layer.

[1] https://w3c.github.io/webpayments-payment-apps-api/#payment-app-manager

BUG=661608
==========

to

==========
PaymentApp: Introduce PaymentAppDatabase class.

Write PaymentAppDatabase class and then just move most of logics to access
database from PaymentAppManager to the new class.

The class is providing APIs to read/write payment app related data(e.g. manifest
and associated service worker). It can be shared between payment_app_manager.cc
and payment_app_context.cc.

The payment_app_manager.cc contains a actual implementation of the
PaymentAppManager interface[1] used on the page or worker.
Also, the payment_app_context.cc can be used to query all manifests data[2]
in order to update payment request UI in Chrome layer.

[1] https://w3c.github.io/webpayments-payment-apps-api/#payment-app-manager

BUG=661608
==========

[zino, 2016-12-14 17:03:43]

jinho.bang@samsung.com changed reviewers:
+ avi@chromium.org, rouslan@chromium.org, tommyt@opera.com

[zino, 2016-12-14 17:03:50]

PTAL

[Avi (use Gerrit), 2016-12-14 17:10:11]

lgtm

https://codereview.chromium.org/2572183002/diff/1/content/browser/payments/pa...
File content/browser/payments/payment_app_context_impl.cc (right):

https://codereview.chromium.org/2572183002/diff/1/content/browser/payments/pa...
content/browser/payments/payment_app_context_impl.cc:76: base::WrapUnique(new
PaymentAppDatabase(service_worker_context));
MakeUnique unless there is some reason you can't use it.

[zino, 2016-12-14 17:27:42]

Avi@, Thank you for review.

PTAL rouslan@ for payments

https://codereview.chromium.org/2572183002/diff/1/content/browser/payments/pa...
File content/browser/payments/payment_app_context_impl.cc (right):

https://codereview.chromium.org/2572183002/diff/1/content/browser/payments/pa...
content/browser/payments/payment_app_context_impl.cc:76: base::WrapUnique(new
PaymentAppDatabase(service_worker_context));
On 2016/12/14 17:10:11, Avi wrote:
> MakeUnique unless there is some reason you can't use it.

Done.

[please use gerrit instead, 2016-12-14 19:44:00]

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
File content/browser/payments/payment_app_context_impl.cc (right):

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
content/browser/payments/payment_app_context_impl.cc:28:
base::Bind(&PaymentAppContextImpl::CreatePaymentAppDatabaseOnIO, this,
Either call this InitOnIO() or rename the Init() method into
CreatePaymentAppDatabase(). The two methods on the different threads should have
similar enough names that it's clear who's calling who.

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
content/browser/payments/payment_app_context_impl.cc:57: PaymentAppDatabase*
PaymentAppContextImpl::payment_app_database() const {
DCHECK IO thread.

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
content/browser/payments/payment_app_context_impl.cc:66:
PaymentAppContextImpl::~PaymentAppContextImpl() {
DCHECK you're on UI thread, same as constructor.

Don't access services_ and payment_app_database_ on the UI thread.

Have a UI-thread-only boolean variable is_shutdown_ instead. Change Shutdown()
to use BrowserThread::PostTaskAndReply() instead of BrowserThread::PostTask().
When the reply comes back to the UI thread, set is_shutdown_=true. Then you can
DCHECK(is_shutdown_); in this destructor.

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
File content/browser/payments/payment_app_context_impl.h (right):

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
content/browser/payments/payment_app_context_impl.h:14: #include
"content/browser/payments/payment_app_database.h"
Forward-declare instead?

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
content/browser/payments/payment_app_context_impl.h:22: 
Add a class comment about the expected order of lifetime calls. Is it this?

1) Constructor
2) Init()
3) CreateService()

Can call GetAllManifests() on UI thread.
Can call ServiceHadConnectionError() and payment_app_database() on IO thread.

4) Shutdown()

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
content/browser/payments/payment_app_context_impl.h:72:
std::map<PaymentAppManager*, std::unique_ptr<PaymentAppManager>> services_;
It's strange that "services_" is a collection of *Manager objects. Can you pick
one name and use it everywhere? Either managers_ here or PaymentAppService
instead of PaymentAppManager.

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
File content/browser/payments/payment_app_manager.cc (right):

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
content/browser/payments/payment_app_manager.cc:58: void
PaymentAppManager::OnConnectionError() {
DCHECK IO thread.

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
File content/browser/payments/payment_app_manager_unittest.cc (right):

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
content/browser/payments/payment_app_manager_unittest.cc:64: nullptr, nullptr,
nullptr, nullptr, nullptr, nullptr, nullptr)) {
Initialize sw_registration_id_(0) here to avoid a period of time when the value
of this variable is random.

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
content/browser/payments/payment_app_manager_unittest.cc:78:
EXPECT_TRUE(called);
Would be nice to have this EXPECT_TRUE(called) also for SetManifest() and
GetManifest() methods below.

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
content/browser/payments/payment_app_manager_unittest.cc:86:
EXPECT_TRUE(manager_);
EXPECT_NE(null, manager_) is better, because manager_ is not a boolean.

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
content/browser/payments/payment_app_manager_unittest.cc:135:
payments::mojom::PaymentAppManifestError error;
Initialize it to something that's not NONE to avoid a bug where "error" is never
set, but it's default value happens to be NONE in some cases or something else
in other cases. For example:

payments::mojom::PaymentAppManifestError error =
payments::mojom::PaymentAppManifestError::MANIFEST_STORAGE_OPERATION_FAILED;

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
content/browser/payments/payment_app_manager_unittest.cc:142:
payments::mojom::PaymentAppManifestError read_error;
init to something other than NONE.

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
content/browser/payments/payment_app_manager_unittest.cc:157:
TEST_F(PaymentAppManagerTest, GetManifestWithoutAssociatedServiceWorker) {
Need a symmetric test case for SetManifestWithoutAssociatedServiceWorker?

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
content/browser/payments/payment_app_manager_unittest.cc:159:
payments::mojom::PaymentAppManifestError read_error;
init to something other than MANIFEST_STORAGE_OPERATION_FAILED.

[zino, 2016-12-15 17:56:53]

I addressed all your comments.

Could you review again?

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
File content/browser/payments/payment_app_context_impl.cc (right):

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
content/browser/payments/payment_app_context_impl.cc:28:
base::Bind(&PaymentAppContextImpl::CreatePaymentAppDatabaseOnIO, this,
On 2016/12/14 19:44:00, rouslan wrote:
> Either call this InitOnIO() or rename the Init() method into
> CreatePaymentAppDatabase(). The two methods on the different threads should
have
> similar enough names that it's clear who's calling who.

The Init() function is paired with Shutdown() and only called in
StorageParitionImpl on UI thread. This currently only creates
a PaymentAppDatabase, but something can be added later.
Instead I'll leave a comment in header file.

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
content/browser/payments/payment_app_context_impl.cc:57: PaymentAppDatabase*
PaymentAppContextImpl::payment_app_database() const {
On 2016/12/14 19:44:00, rouslan wrote:
> DCHECK IO thread.

Done.

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
content/browser/payments/payment_app_context_impl.cc:66:
PaymentAppContextImpl::~PaymentAppContextImpl() {
On 2016/12/14 19:44:00, rouslan wrote:
> DCHECK you're on UI thread, same as constructor.
> 
> Don't access services_ and payment_app_database_ on the UI thread.
> 
> Have a UI-thread-only boolean variable is_shutdown_ instead. Change Shutdown()
> to use BrowserThread::PostTaskAndReply() instead of BrowserThread::PostTask().
> When the reply comes back to the UI thread, set is_shutdown_=true. Then you
can
> DCHECK(is_shutdown_); in this destructor.

Done.

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
File content/browser/payments/payment_app_context_impl.h (right):

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
content/browser/payments/payment_app_context_impl.h:14: #include
"content/browser/payments/payment_app_database.h"
On 2016/12/14 19:44:00, rouslan wrote:
> Forward-declare instead?

Done.

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
content/browser/payments/payment_app_context_impl.h:22: 
On 2016/12/14 19:44:00, rouslan wrote:
> Add a class comment about the expected order of lifetime calls. Is it this?
> 
> 1) Constructor
> 2) Init()
> 3) CreateService()
> 
> Can call GetAllManifests() on UI thread.
> Can call ServiceHadConnectionError() and payment_app_database() on IO thread.
> 
> 4) Shutdown()

Done.

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
content/browser/payments/payment_app_context_impl.h:72:
std::map<PaymentAppManager*, std::unique_ptr<PaymentAppManager>> services_;
On 2016/12/14 19:44:00, rouslan wrote:
> It's strange that "services_" is a collection of *Manager objects. Can you
pick
> one name and use it everywhere? Either managers_ here or PaymentAppService
> instead of PaymentAppManager.

Done.

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
File content/browser/payments/payment_app_manager.cc (right):

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
content/browser/payments/payment_app_manager.cc:58: void
PaymentAppManager::OnConnectionError() {
On 2016/12/14 19:44:00, rouslan wrote:
> DCHECK IO thread.

Done.

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
File content/browser/payments/payment_app_manager_unittest.cc (right):

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
content/browser/payments/payment_app_manager_unittest.cc:64: nullptr, nullptr,
nullptr, nullptr, nullptr, nullptr, nullptr)) {
On 2016/12/14 19:44:00, rouslan wrote:
> Initialize sw_registration_id_(0) here to avoid a period of time when the
value
> of this variable is random.

Done.

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
content/browser/payments/payment_app_manager_unittest.cc:78:
EXPECT_TRUE(called);
On 2016/12/14 19:44:00, rouslan wrote:
> Would be nice to have this EXPECT_TRUE(called) also for SetManifest() and
> GetManifest() methods below.

Done.

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
content/browser/payments/payment_app_manager_unittest.cc:135:
payments::mojom::PaymentAppManifestError error;
On 2016/12/14 19:44:00, rouslan wrote:
> Initialize it to something that's not NONE to avoid a bug where "error" is
never
> set, but it's default value happens to be NONE in some cases or something else
> in other cases. For example:
> 
> payments::mojom::PaymentAppManifestError error =
> payments::mojom::PaymentAppManifestError::MANIFEST_STORAGE_OPERATION_FAILED;

Done.

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
content/browser/payments/payment_app_manager_unittest.cc:142:
payments::mojom::PaymentAppManifestError read_error;
On 2016/12/14 19:44:00, rouslan wrote:
> init to something other than NONE.

Done.

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
content/browser/payments/payment_app_manager_unittest.cc:157:
TEST_F(PaymentAppManagerTest, GetManifestWithoutAssociatedServiceWorker) {
On 2016/12/14 19:44:00, rouslan wrote:
> Need a symmetric test case for SetManifestWithoutAssociatedServiceWorker?

The name was confusing.
Rename the test to GetManifestWithNoSavedManifest and then add two tests for no
associated SW.

Done.

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
content/browser/payments/payment_app_manager_unittest.cc:159:
payments::mojom::PaymentAppManifestError read_error;
On 2016/12/14 19:44:00, rouslan wrote:
> init to something other than MANIFEST_STORAGE_OPERATION_FAILED.

Done.

[please use gerrit instead, 2016-12-15 19:24:31]

https://codereview.chromium.org/2572183002/diff/80001/content/browser/payment...
File content/browser/payments/payment_app_context_impl.cc (right):

https://codereview.chromium.org/2572183002/diff/80001/content/browser/payment...
content/browser/payments/payment_app_context_impl.cc:101:
DCHECK(!payment_app_database_);
1) For the sake of thread-safety, don't access payment_app_managers_ and
payment_app_database_ on UI thread. Please remove lines 100-101.

2) DidShutdown() is a private method, so it can be called only from this file. A
quick glance through this file shows that DidShutdown() is called only after
SthudwonOnIO(), which clears the data on IO thread. Therefore, it's easy to see
that the code is correct and there's no need for DCHECKS().

https://codereview.chromium.org/2572183002/diff/80001/content/browser/payment...
File content/browser/payments/payment_app_context_impl.h (right):

https://codereview.chromium.org/2572183002/diff/80001/content/browser/payment...
content/browser/payments/payment_app_context_impl.h:36: //   3) Can call other
public methods in this class at last.
Any order is OK?

https://codereview.chromium.org/2572183002/diff/80001/content/browser/payment...
File content/browser/payments/payment_app_manager.cc (right):

https://codereview.chromium.org/2572183002/diff/80001/content/browser/payment...
content/browser/payments/payment_app_manager.cc:13: #include
"content/browser/payments/payment_app_database.h"
Does not seem necessary.

https://codereview.chromium.org/2572183002/diff/80001/content/browser/payment...
File content/browser/payments/payment_app_manager_unittest.cc (right):

https://codereview.chromium.org/2572183002/diff/80001/content/browser/payment...
content/browser/payments/payment_app_manager_unittest.cc:100: nullptr)),
Oh boy! Is this clang-format?

[zino, 2016-12-15 23:33:57]

Thank you for review.

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
File content/browser/payments/payment_app_manager_unittest.cc (right):

https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...
content/browser/payments/payment_app_manager_unittest.cc:86:
EXPECT_TRUE(manager_);
On 2016/12/14 19:44:00, rouslan wrote:
> EXPECT_NE(null, manager_) is better, because manager_ is not a boolean.

Done.

https://codereview.chromium.org/2572183002/diff/80001/content/browser/payment...
File content/browser/payments/payment_app_context_impl.cc (right):

https://codereview.chromium.org/2572183002/diff/80001/content/browser/payment...
content/browser/payments/payment_app_context_impl.cc:101:
DCHECK(!payment_app_database_);
On 2016/12/15 19:24:31, rouslan wrote:
> 1) For the sake of thread-safety, don't access payment_app_managers_ and
> payment_app_database_ on UI thread. Please remove lines 100-101.
> 
> 2) DidShutdown() is a private method, so it can be called only from this file.
A
> quick glance through this file shows that DidShutdown() is called only after
> SthudwonOnIO(), which clears the data on IO thread. Therefore, it's easy to
see
> that the code is correct and there's no need for DCHECKS().

Done.

https://codereview.chromium.org/2572183002/diff/80001/content/browser/payment...
File content/browser/payments/payment_app_context_impl.h (right):

https://codereview.chromium.org/2572183002/diff/80001/content/browser/payment...
content/browser/payments/payment_app_context_impl.h:36: //   3) Can call other
public methods in this class at last.
On 2016/12/15 19:24:31, rouslan wrote:
> Any order is OK?

Yes, I also update the comment.

https://codereview.chromium.org/2572183002/diff/80001/content/browser/payment...
File content/browser/payments/payment_app_manager.cc (right):

https://codereview.chromium.org/2572183002/diff/80001/content/browser/payment...
content/browser/payments/payment_app_manager.cc:13: #include
"content/browser/payments/payment_app_database.h"
On 2016/12/15 19:24:31, rouslan wrote:
> Does not seem necessary.

It's necessary to call WriteManifest() and ReadManifest().

Now, I use forward declare for PaymentAppDatabase in payment_app_context_impl.h
according to your previous comment.
https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...

https://codereview.chromium.org/2572183002/diff/80001/content/browser/payment...
File content/browser/payments/payment_app_manager_unittest.cc (right):

https://codereview.chromium.org/2572183002/diff/80001/content/browser/payment...
content/browser/payments/payment_app_manager_unittest.cc:100: nullptr)),
On 2016/12/15 19:24:31, rouslan wrote:
> Oh boy! Is this clang-format?

Yes :(
But, fortuneately the problem was solved after rebasing due to changing
storage_partition_impl.cc:
https://codereview.chromium.org/1782053004

[zino, 2016-12-15 23:47:49]

The CQ bit was checked by jinho.bang@samsung.com to run a CQ dry run

[commit-bot: I haz the power, 2016-12-15 23:48:59]

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

[zino, 2016-12-15 23:53:00]

Description was changed from

==========
PaymentApp: Introduce PaymentAppDatabase class.

Write PaymentAppDatabase class and then just move most of logics to access
database from PaymentAppManager to the new class.

The class is providing APIs to read/write payment app related data(e.g. manifest
and associated service worker). It can be shared between payment_app_manager.cc
and payment_app_context.cc.

The payment_app_manager.cc contains a actual implementation of the
PaymentAppManager interface[1] used on the page or worker.
Also, the payment_app_context.cc can be used to query all manifests data[2]
in order to update payment request UI in Chrome layer.

[1] https://w3c.github.io/webpayments-payment-apps-api/#payment-app-manager

BUG=661608
==========

to

==========
PaymentApp: Introduce PaymentAppDatabase class.

Write PaymentAppDatabase class and then just move most of logics to access
database from PaymentAppManager to the new class.

The class is providing APIs to read/write payment app related data(e.g. manifest
and associated service worker). It can be shared between payment_app_manager.cc
and payment_app_context.cc.

The payment_app_manager.cc contains a actual implementation of the
PaymentAppManager interface[1] used on the page or worker.
Also, the payment_app_context.cc can be used to query all manifests data.
in order to update payment request UI in Chrome layer.

[1] https://w3c.github.io/webpayments-payment-apps-api/#payment-app-manager

BUG=661608
==========

[commit-bot: I haz the power, 2016-12-16 01:42:08]

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

[commit-bot: I haz the power, 2016-12-16 01:42:10]

Dry run: This issue passed the CQ dry run.

[please use gerrit instead, 2016-12-16 14:25:56]

lgtm

https://codereview.chromium.org/2572183002/diff/80001/content/browser/payment...
File content/browser/payments/payment_app_manager.cc (right):

https://codereview.chromium.org/2572183002/diff/80001/content/browser/payment...
content/browser/payments/payment_app_manager.cc:13: #include
"content/browser/payments/payment_app_database.h"
On 2016/12/15 23:33:56, zino wrote:
> On 2016/12/15 19:24:31, rouslan wrote:
> > Does not seem necessary.
> 
> It's necessary to call WriteManifest() and ReadManifest().
> 
> Now, I use forward declare for PaymentAppDatabase in
payment_app_context_impl.h
> according to your previous comment.
>
https://codereview.chromium.org/2572183002/diff/60001/content/browser/payment...

Acknowledged.

https://codereview.chromium.org/2572183002/diff/80001/content/browser/payment...
File content/browser/payments/payment_app_manager_unittest.cc (right):

https://codereview.chromium.org/2572183002/diff/80001/content/browser/payment...
content/browser/payments/payment_app_manager_unittest.cc:100: nullptr)),
On 2016/12/15 23:33:57, zino wrote:
> On 2016/12/15 19:24:31, rouslan wrote:
> > Oh boy! Is this clang-format?
> 
> Yes :(
> But, fortuneately the problem was solved after rebasing due to changing
> storage_partition_impl.cc:
> https://codereview.chromium.org/1782053004

Much better.

[zino, 2016-12-16 14:30:17]

The CQ bit was checked by jinho.bang@samsung.com

[zino, 2016-12-16 14:30:17]

The patchset sent to the CQ was uploaded after l-g-t-m from avi@chromium.org
Link to the patchset: https://codereview.chromium.org/2572183002/#ps100001
(title: "rebase")

[commit-bot: I haz the power, 2016-12-16 14:30:27]

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, 2016-12-16 14:34:04]

CQ is committing da patch.

Bot data: {"patchset_id": 100001, "attempt_start_ts": 1481898617091810,
"parent_rev": "f7ab200c4611b2b0577b20ce097f5c0374d5960b", "commit_rev":
"c1d5130cad0e688ad114ecd8bedda38515ce44df"}

[commit-bot: I haz the power, 2016-12-16 14:34:33]

Description was changed from

==========
PaymentApp: Introduce PaymentAppDatabase class.

Write PaymentAppDatabase class and then just move most of logics to access
database from PaymentAppManager to the new class.

The class is providing APIs to read/write payment app related data(e.g. manifest
and associated service worker). It can be shared between payment_app_manager.cc
and payment_app_context.cc.

The payment_app_manager.cc contains a actual implementation of the
PaymentAppManager interface[1] used on the page or worker.
Also, the payment_app_context.cc can be used to query all manifests data.
in order to update payment request UI in Chrome layer.

[1] https://w3c.github.io/webpayments-payment-apps-api/#payment-app-manager

BUG=661608
==========

to

==========
PaymentApp: Introduce PaymentAppDatabase class.

Write PaymentAppDatabase class and then just move most of logics to access
database from PaymentAppManager to the new class.

The class is providing APIs to read/write payment app related data(e.g. manifest
and associated service worker). It can be shared between payment_app_manager.cc
and payment_app_context.cc.

The payment_app_manager.cc contains a actual implementation of the
PaymentAppManager interface[1] used on the page or worker.
Also, the payment_app_context.cc can be used to query all manifests data.
in order to update payment request UI in Chrome layer.

[1] https://w3c.github.io/webpayments-payment-apps-api/#payment-app-manager

BUG=661608

Review-Url: https://codereview.chromium.org/2572183002
==========

[commit-bot: I haz the power, 2016-12-16 14:34:35]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2016-12-16 14:36:40]

Description was changed from

==========
PaymentApp: Introduce PaymentAppDatabase class.

Write PaymentAppDatabase class and then just move most of logics to access
database from PaymentAppManager to the new class.

The class is providing APIs to read/write payment app related data(e.g. manifest
and associated service worker). It can be shared between payment_app_manager.cc
and payment_app_context.cc.

The payment_app_manager.cc contains a actual implementation of the
PaymentAppManager interface[1] used on the page or worker.
Also, the payment_app_context.cc can be used to query all manifests data.
in order to update payment request UI in Chrome layer.

[1] https://w3c.github.io/webpayments-payment-apps-api/#payment-app-manager

BUG=661608

Review-Url: https://codereview.chromium.org/2572183002
==========

to

==========
PaymentApp: Introduce PaymentAppDatabase class.

Write PaymentAppDatabase class and then just move most of logics to access
database from PaymentAppManager to the new class.

The class is providing APIs to read/write payment app related data(e.g. manifest
and associated service worker). It can be shared between payment_app_manager.cc
and payment_app_context.cc.

The payment_app_manager.cc contains a actual implementation of the
PaymentAppManager interface[1] used on the page or worker.
Also, the payment_app_context.cc can be used to query all manifests data.
in order to update payment request UI in Chrome layer.

[1] https://w3c.github.io/webpayments-payment-apps-api/#payment-app-manager

BUG=661608

Committed: https://crrev.com/ab43057199ce68c2e9264fa98c9bd24cc1be4fd8
Cr-Commit-Position: refs/heads/master@{#439100}
==========

[commit-bot: I haz the power, 2016-12-16 14:36:41]

Patchset 6 (id:??) landed as
https://crrev.com/ab43057199ce68c2e9264fa98c9bd24cc1be4fd8
Cr-Commit-Position: refs/heads/master@{#439100}