Introduce Identity Service and its initial usage

Introduce Identity Service and its initial usage

This CL introduces the Identity Service and converts the implementation
of the chrome.identity.GetProfileUserInfo() extension function to use
the new service. Notable points:

- The Identity Service is embedded in //chrome rather than //content,
  as it needs access to per-Profile classes with //chrome-level
  factories.
- The initial API is simply enough to satisfy the needs of the initial
  consumer. We will build out this API by incrementally converting
  further consumers.
- In the long term, the //components/signin classes on which the
  Identity Service depends will be folded into the Identity Service
  implementation, and their consumers will be converted to consume the
  Identity Service.
- The Identity Service makes use of the existing AccountId Mojo struct.
  It extends that struct to be nullable, as the Identity Service needs
  to be able to convey to a requesting client that the user is not
  signed in. Note that a separate HasPrimaryAccount() => bool method
  would not suffice here: since the communication is asynchronous, the
  user could always have signed out by the time that the Identity
  Service receives the GetPrimaryAccountId() call.

BUG=683120, 683124
TEST=Install a Chrome extension with the identity and identity.email
permissions in its manifest. Go to chrome://extensions, enable developer mode,
and inspect the background page of the above app. At the JS console that that
brings up, execute:
chrome.identity.getProfileUserInfo((account) => {console.log(account)})
Verify that the printout corresponds to the information of the account
being used for sync.

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

[blundell, 2017-03-16 12:52:39]

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

[commit-bot: I haz the power, 2017-03-16 12:52:53]

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-16 13:00:23]

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

[commit-bot: I haz the power, 2017-03-16 13:00:24]

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

[blundell, 2017-03-20 15:28:39]

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

[commit-bot: I haz the power, 2017-03-20 15:29:19]

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-20 16:46:52]

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

[commit-bot: I haz the power, 2017-03-20 16:46:53]

Dry run: This issue passed the CQ dry run.

[blundell, 2017-03-21 09:51:29]

Description was changed from

==========
Introduce Identity Service and its initial usage

BUG=683120, 683124
==========

to

==========
Introduce Identity Service and its initial usage

This CL introduces the Identity Service and converts the implementation
of the chrome.identity.GetProfileUserInfo() extension function to use
the new service. Notable points:

- The Identity Service is embedded in //chrome rather than //content,
  as it needs access to per-Profile classes with //chrome-level
  factories.
- The initial API is simply enough to satisfy the needs of the initial
  consumer. We will build out this API by incrementally converting
  further consumers.
- In the long term, the //components/signin classes on which the
  Identity Service depends will be folded into the Identity Service
  implementation, and their consumers will be converted to consume the
  Identity Service.
- The Identity Service makes use of the existing AccountId Mojo struct.
  It extends that struct to be nullable, as the Identity Service needs
  to be able to convey to a requesting client that the user is not
  signed in. Note that a separate HasPrimaryAccount() => bool method
  would not suffice here: since the communication is asynchronous, the
  user could always have signed out by the time that the Identity
  Service receives the GetPrimaryAccountId() call.

BUG=683120, 683124
==========

[blundell, 2017-03-21 10:10:06]

Description was changed from

==========
Introduce Identity Service and its initial usage

This CL introduces the Identity Service and converts the implementation
of the chrome.identity.GetProfileUserInfo() extension function to use
the new service. Notable points:

- The Identity Service is embedded in //chrome rather than //content,
  as it needs access to per-Profile classes with //chrome-level
  factories.
- The initial API is simply enough to satisfy the needs of the initial
  consumer. We will build out this API by incrementally converting
  further consumers.
- In the long term, the //components/signin classes on which the
  Identity Service depends will be folded into the Identity Service
  implementation, and their consumers will be converted to consume the
  Identity Service.
- The Identity Service makes use of the existing AccountId Mojo struct.
  It extends that struct to be nullable, as the Identity Service needs
  to be able to convey to a requesting client that the user is not
  signed in. Note that a separate HasPrimaryAccount() => bool method
  would not suffice here: since the communication is asynchronous, the
  user could always have signed out by the time that the Identity
  Service receives the GetPrimaryAccountId() call.

BUG=683120, 683124
==========

to

==========
Introduce Identity Service and its initial usage

This CL introduces the Identity Service and converts the implementation
of the chrome.identity.GetProfileUserInfo() extension function to use
the new service. Notable points:

- The Identity Service is embedded in //chrome rather than //content,
  as it needs access to per-Profile classes with //chrome-level
  factories.
- The initial API is simply enough to satisfy the needs of the initial
  consumer. We will build out this API by incrementally converting
  further consumers.
- In the long term, the //components/signin classes on which the
  Identity Service depends will be folded into the Identity Service
  implementation, and their consumers will be converted to consume the
  Identity Service.
- The Identity Service makes use of the existing AccountId Mojo struct.
  It extends that struct to be nullable, as the Identity Service needs
  to be able to convey to a requesting client that the user is not
  signed in. Note that a separate HasPrimaryAccount() => bool method
  would not suffice here: since the communication is asynchronous, the
  user could always have signed out by the time that the Identity
  Service receives the GetPrimaryAccountId() call.

BUG=683120, 683124
TEST=Install
https://github.com/GoogleChrome/chrome-app-samples/tree/master/samples/identity.
Go to chrome://extensions and inspect the background page
of the above app. At the JS console that that brings up, execute:
chrome.identity.getProfileUserInfo((account) => {console.log(account)})
Verify that the printout corresponds to the information of the account being
used for sync.
==========

[blundell, 2017-03-21 10:29:57]

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

[commit-bot: I haz the power, 2017-03-21 10:30:10]

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

[blundell, 2017-03-21 10:32:06]

blundell@chromium.org changed reviewers:
+ msarda@chromium.org, rockot@chromium.org

[blundell, 2017-03-21 10:32:07]

rockot@: Whole CL.
msarda@: As //services/identity OWNER.

I'm working on bringing up a service test for the Identity Service.

[commit-bot: I haz the power, 2017-03-21 11:57:41]

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

[commit-bot: I haz the power, 2017-03-21 11:57:42]

Dry run: This issue passed the CQ dry run.

[Ken Rockot(use gerrit already), 2017-03-21 14:53:09]

Very nice, everything LGTM on my end

https://codereview.chromium.org/2753753007/diff/40001/chrome/browser/extensio...
File
chrome/browser/extensions/api/identity/identity_get_profile_user_info_function.cc
(right):

https://codereview.chromium.org/2753753007/diff/40001/chrome/browser/extensio...
chrome/browser/extensions/api/identity/identity_get_profile_user_info_function.cc:29:
if (!identity_manager_.is_bound()) {
It's been a while, but IIRC this test is redundant because we never Run() a
function instance more than once, i.e. an instance is created for every API
call. Could omit this or at worst make it a DCHECK

Ideally we would just have the renderer maintain an IdentityManagerPtr, and the
native bindings for this API use that Ptr directly. I wonder if we could do this
relatively painlessly in a follow-up CL. It would be a nice end-to-end
demonstration of the "correct" way to convert an extension API to use services.

https://codereview.chromium.org/2753753007/diff/40001/chrome/browser/profiles...
File chrome/browser/profiles/DEPS (right):

https://codereview.chromium.org/2753753007/diff/40001/chrome/browser/profiles...
chrome/browser/profiles/DEPS:11: "+services/identity",
This could be more specifically "+services/identity/identity_service.h" since
chrome/browser/DEPS adds public/interfaces.

https://codereview.chromium.org/2753753007/diff/40001/services/identity/publi...
File services/identity/public/interfaces/identity_manager.mojom (right):

https://codereview.chromium.org/2753753007/diff/40001/services/identity/publi...
services/identity/public/interfaces/identity_manager.mojom:13: 
nitty nit: I know we don't have a mojom style guide and I've probably failed to
comment on this before, but I don't think we should encourage a leading vertical
whitespace. We don't do this for classes or structs or any other kinds of
delimited blocks in other languages.

[blundell, 2017-03-21 16:08:47]

https://codereview.chromium.org/2753753007/diff/40001/chrome/browser/extensio...
File
chrome/browser/extensions/api/identity/identity_get_profile_user_info_function.cc
(right):

https://codereview.chromium.org/2753753007/diff/40001/chrome/browser/extensio...
chrome/browser/extensions/api/identity/identity_get_profile_user_info_function.cc:29:
if (!identity_manager_.is_bound()) {
On 2017/03/21 14:53:09, Ken Rockot wrote:
> It's been a while, but IIRC this test is redundant because we never Run() a
> function instance more than once, i.e. an instance is created for every API
> call. Could omit this or at worst make it a DCHECK
> 
> Ideally we would just have the renderer maintain an IdentityManagerPtr, and
the
> native bindings for this API use that Ptr directly. I wonder if we could do
this
> relatively painlessly in a follow-up CL. It would be a nice end-to-end
> demonstration of the "correct" way to convert an extension API to use
services.

+1000, I'd love to use this effort as a demonstration of the potential win wrt
extensions here. I'm totally willing to add some extra eng investment if that's
a possibility.

[msarda, 2017-03-23 10:48:57]

LGTM with nits and some general questions about services in general.

https://codereview.chromium.org/2753753007/diff/40001/chrome/browser/extensio...
File
chrome/browser/extensions/api/identity/identity_get_profile_user_info_function.cc
(right):

https://codereview.chromium.org/2753753007/diff/40001/chrome/browser/extensio...
chrome/browser/extensions/api/identity/identity_get_profile_user_info_function.cc:44:
if (account_id && extension()->permissions_data()->HasAPIPermission(
I think there is no point in making a call to get the primary account info if
the extension does not have the API identity.email permissions. Consider moving
this check before calling the service.

https://codereview.chromium.org/2753753007/diff/40001/chrome/browser/profiles...
File chrome/browser/profiles/profile_impl.h (right):

https://codereview.chromium.org/2753753007/diff/40001/chrome/browser/profiles...
chrome/browser/profiles/profile_impl.h:201:
std::unique_ptr<service_manager::Service> CreateIdentityService();
Is it the goal to add the services as part of the Profile object. On downside I
can think of is that this will not work on iOS.

https://codereview.chromium.org/2753753007/diff/40001/components/signin/publi...
File components/signin/public/interfaces/account_id_traits.h (right):

https://codereview.chromium.org/2753753007/diff/40001/components/signin/publi...
components/signin/public/interfaces/account_id_traits.h:104: static bool
IsNull(const AccountId& input) { return !input.is_valid(); }
I suppose these are standard naming conventions for Mojo interfaces, right?

https://codereview.chromium.org/2753753007/diff/40001/services/identity/READM...
File services/identity/README.md (right):

https://codereview.chromium.org/2753753007/diff/40001/services/identity/READM...
services/identity/README.md:6:
https://docs.google.com/document/d/1EPLEJTZewjiShBemNP5Zyk3b_9sgdbrZlXn7j1fub...
It looks like I get an error when I try to access this document (could it be the
account that I am using?)

[blundell, 2017-03-23 16:38:38]

blundell@chromium.org changed reviewers:
+ tsepez@chromium.org

[blundell, 2017-03-23 16:38:39]

tsepez@: Can you do a security review of the new mojoms and the manifest change?
Thanks!

[blundell, 2017-03-23 16:39:26]

blundell@chromium.org changed reviewers:
+ thakis@chromium.org

[blundell, 2017-03-23 16:39:27]

thakis@: Can you do an OWNERS review of //chrome? Thanks!

[Tom Sepez, 2017-03-23 16:53:18]

Can you give me some background on account IDs?

Are these IDs guessable?

How does the service maintain the binding between clients and the ID to be
returned by your mojom?  In a multi-profile world, do different browser-windows
see different IDs?

Having obtained an ID, presumably it will be used in future to-be-added calls? 
What happens if the client sends back crafted IDs of its choosing?

[msarda, 2017-03-23 17:12:38]

On 2017/03/23 16:53:18, Tom Sepez wrote:
> Can you give me some background on account IDs?
> 
> Are these IDs guessable?
> 
> How does the service maintain the binding between clients and the ID to be
> returned by your mojom?  In a multi-profile world, do different
browser-windows
> see different IDs?
> 
> Having obtained an ID, presumably it will be used in future to-be-added calls?

> What happens if the client sends back crafted IDs of its choosing?

You can consider the account ID as a synthetic value that Chrome knows how to
map to an AccountInfo (see
https://cs.chromium.org/chromium/src/components/signin/core/browser/signin_ma...
). In practice this maps to the obfuscated Gaia ID of the account (or to the
email), depending on whether we migrated the account identifier from the email
to the Gaia ID.
We may consider changing the API from GetPrimaryAccountID to
GetPrimaryAccountIDInfo and that would return the value of
https://cs.chromium.org/chromium/src/components/signin/core/browser/signin_ma...

[Nico, 2017-03-23 17:40:35]

chrome/OWNERS lgtm

Is there a design doc for The Identity Service, or for services/ in general? I
hadn't see that directory before.

[Tom Sepez, 2017-03-23 18:12:34]

lgtm

[blundell, 2017-03-24 09:33:37]

Description was changed from

==========
Introduce Identity Service and its initial usage

This CL introduces the Identity Service and converts the implementation
of the chrome.identity.GetProfileUserInfo() extension function to use
the new service. Notable points:

- The Identity Service is embedded in //chrome rather than //content,
  as it needs access to per-Profile classes with //chrome-level
  factories.
- The initial API is simply enough to satisfy the needs of the initial
  consumer. We will build out this API by incrementally converting
  further consumers.
- In the long term, the //components/signin classes on which the
  Identity Service depends will be folded into the Identity Service
  implementation, and their consumers will be converted to consume the
  Identity Service.
- The Identity Service makes use of the existing AccountId Mojo struct.
  It extends that struct to be nullable, as the Identity Service needs
  to be able to convey to a requesting client that the user is not
  signed in. Note that a separate HasPrimaryAccount() => bool method
  would not suffice here: since the communication is asynchronous, the
  user could always have signed out by the time that the Identity
  Service receives the GetPrimaryAccountId() call.

BUG=683120, 683124
TEST=Install
https://github.com/GoogleChrome/chrome-app-samples/tree/master/samples/identity.
Go to chrome://extensions and inspect the background page
of the above app. At the JS console that that brings up, execute:
chrome.identity.getProfileUserInfo((account) => {console.log(account)})
Verify that the printout corresponds to the information of the account being
used for sync.
==========

to

==========
Introduce Identity Service and its initial usage

This CL introduces the Identity Service and converts the implementation
of the chrome.identity.GetProfileUserInfo() extension function to use
the new service. Notable points:

- The Identity Service is embedded in //chrome rather than //content,
  as it needs access to per-Profile classes with //chrome-level
  factories.
- The initial API is simply enough to satisfy the needs of the initial
  consumer. We will build out this API by incrementally converting
  further consumers.
- In the long term, the //components/signin classes on which the
  Identity Service depends will be folded into the Identity Service
  implementation, and their consumers will be converted to consume the
  Identity Service.
- The Identity Service makes use of the existing AccountId Mojo struct.
  It extends that struct to be nullable, as the Identity Service needs
  to be able to convey to a requesting client that the user is not
  signed in. Note that a separate HasPrimaryAccount() => bool method
  would not suffice here: since the communication is asynchronous, the
  user could always have signed out by the time that the Identity
  Service receives the GetPrimaryAccountId() call.

BUG=683120, 683124
TEST=Install a Chrome extension with the identity and identity.email
permissions in its manifest. Go to chrome://extensions, enable developer mode,
and inspect the background page of the above app. At the JS console that that
brings up, execute:
chrome.identity.getProfileUserInfo((account) => {console.log(account)})
Verify that the printout corresponds to the information of the account
being used for sync.
==========

[blundell, 2017-03-24 09:36:43]

On 2017/03/23 17:40:35, Nico wrote:
> chrome/OWNERS lgtm
> 
> Is there a design doc for The Identity Service, or for services/ in general? I
> hadn't see that directory before.

The motivating doc for the servicification effort:
https://docs.google.com/document/d/15I7sQyQo6zsqXVNAlVd520tdGaS8FCicZHrN0yRu-...
Overview of //services, with links to more info:
https://cs.chromium.org/chromium/src/services/README.md?q=services/README+pac...
Identity Service design doc:
https://docs.google.com/document/d/1EPLEJTZewjiShBemNP5Zyk3b_9sgdbrZlXn7j1fub...

[blundell, 2017-03-24 09:37:59]

Thanks, everyone! Ken, I'm going to land this and add initial service tests of
the Identity Service in a followup.

https://codereview.chromium.org/2753753007/diff/40001/chrome/browser/extensio...
File
chrome/browser/extensions/api/identity/identity_get_profile_user_info_function.cc
(right):

https://codereview.chromium.org/2753753007/diff/40001/chrome/browser/extensio...
chrome/browser/extensions/api/identity/identity_get_profile_user_info_function.cc:29:
if (!identity_manager_.is_bound()) {
On 2017/03/21 14:53:09, Ken Rockot wrote:
> It's been a while, but IIRC this test is redundant because we never Run() a
> function instance more than once, i.e. an instance is created for every API
> call. Could omit this or at worst make it a DCHECK
> 
> Ideally we would just have the renderer maintain an IdentityManagerPtr, and
the
> native bindings for this API use that Ptr directly. I wonder if we could do
this
> relatively painlessly in a follow-up CL. It would be a nice end-to-end
> demonstration of the "correct" way to convert an extension API to use
services.

Done.

https://codereview.chromium.org/2753753007/diff/40001/chrome/browser/extensio...
chrome/browser/extensions/api/identity/identity_get_profile_user_info_function.cc:44:
if (account_id && extension()->permissions_data()->HasAPIPermission(
On 2017/03/23 10:48:57, msarda wrote:
> I think there is no point in making a call to get the primary account info if
> the extension does not have the API identity.email permissions. Consider
moving
> this check before calling the service.

Done.

https://codereview.chromium.org/2753753007/diff/40001/chrome/browser/profiles...
File chrome/browser/profiles/DEPS (right):

https://codereview.chromium.org/2753753007/diff/40001/chrome/browser/profiles...
chrome/browser/profiles/DEPS:11: "+services/identity",
On 2017/03/21 14:53:09, Ken Rockot wrote:
> This could be more specifically "+services/identity/identity_service.h" since
> chrome/browser/DEPS adds public/interfaces.

Done.

https://codereview.chromium.org/2753753007/diff/40001/chrome/browser/profiles...
File chrome/browser/profiles/profile_impl.h (right):

https://codereview.chromium.org/2753753007/diff/40001/chrome/browser/profiles...
chrome/browser/profiles/profile_impl.h:201:
std::unique_ptr<service_manager::Service> CreateIdentityService();
On 2017/03/23 10:48:57, msarda wrote:
> Is it the goal to add the services as part of the Profile object. On downside
I
> can think of is that this will not work on iOS.

It's neither a goal nor a non-goal, but is a tool that can be used when
necessary. In this case it's necessary because the Identity Service needs to be
passed per-Profile classes on its creation. When bringing up services on iOS,
we'll add a corresponding mechanism to attach service creation to
ChromeBrowserState.

In the long term, the Identity Service will be able to instantiate the classes
that it needs internally, because there won't be any other direct consumers of
those classes. Once we've reached that point (which is far down the road
obviously), the Identity Service won't need to be created by the Profile
anymore.

https://codereview.chromium.org/2753753007/diff/40001/components/signin/publi...
File components/signin/public/interfaces/account_id_traits.h (right):

https://codereview.chromium.org/2753753007/diff/40001/components/signin/publi...
components/signin/public/interfaces/account_id_traits.h:104: static bool
IsNull(const AccountId& input) { return !input.is_valid(); }
On 2017/03/23 10:48:57, msarda wrote:
> I suppose these are standard naming conventions for Mojo interfaces, right?

Yes. They're what allow a typemapped type to be declared nullable at the mojom
level (i.e., the ? in the return type). Lots of info here:
https://www.chromium.org/developers/design-documents/mojo/type-mapping#TOC-Ov...

https://codereview.chromium.org/2753753007/diff/40001/services/identity/READM...
File services/identity/README.md (right):

https://codereview.chromium.org/2753753007/diff/40001/services/identity/READM...
services/identity/README.md:6:
https://docs.google.com/document/d/1EPLEJTZewjiShBemNP5Zyk3b_9sgdbrZlXn7j1fub...
Ah, the UI here inserts a space if you copy-paste the link. I just removed the
trailing "/edit", which makes it all fit on one line.

https://codereview.chromium.org/2753753007/diff/40001/services/identity/publi...
File services/identity/public/interfaces/identity_manager.mojom (right):

https://codereview.chromium.org/2753753007/diff/40001/services/identity/publi...
services/identity/public/interfaces/identity_manager.mojom:13: 
On 2017/03/21 14:53:09, Ken Rockot wrote:
> nitty nit: I know we don't have a mojom style guide and I've probably failed
to
> comment on this before, but I don't think we should encourage a leading
vertical
> whitespace. We don't do this for classes or structs or any other kinds of
> delimited blocks in other languages.

Done.

[blundell, 2017-03-24 09:38:08]

The CQ bit was checked by blundell@chromium.org

[blundell, 2017-03-24 09:38:09]

The patchset sent to the CQ was uploaded after l-g-t-m from tsepez@chromium.org,
rockot@chromium.org, thakis@chromium.org, msarda@chromium.org
Link to the patchset: https://codereview.chromium.org/2753753007/#ps80001
(title: "Response to reviews")

[commit-bot: I haz the power, 2017-03-24 09:38:19]

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-24 09:45:36]

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

[commit-bot: I haz the power, 2017-03-24 09:45:38]

Try jobs failed on following builders:
  android_clang_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...)
  chromeos_daisy_chromium_compile_only_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_daisy_...)
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
  linux_chromium_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_...)
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)

[blundell, 2017-03-24 12:19:44]

The CQ bit was checked by blundell@chromium.org

[commit-bot: I haz the power, 2017-03-24 12:19:56]

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-24 13:56:32]

CQ is committing da patch.

Bot data: {"patchset_id": 80001, "attempt_start_ts": 1490357984192440,
"parent_rev": "82246449cc0caa5d1930d4205b580cb4a634d24a", "commit_rev":
"b85bd3b039159890285ab7df4bf280f89cd9980f"}

[commit-bot: I haz the power, 2017-03-24 13:57:21]

Description was changed from

==========
Introduce Identity Service and its initial usage

This CL introduces the Identity Service and converts the implementation
of the chrome.identity.GetProfileUserInfo() extension function to use
the new service. Notable points:

- The Identity Service is embedded in //chrome rather than //content,
  as it needs access to per-Profile classes with //chrome-level
  factories.
- The initial API is simply enough to satisfy the needs of the initial
  consumer. We will build out this API by incrementally converting
  further consumers.
- In the long term, the //components/signin classes on which the
  Identity Service depends will be folded into the Identity Service
  implementation, and their consumers will be converted to consume the
  Identity Service.
- The Identity Service makes use of the existing AccountId Mojo struct.
  It extends that struct to be nullable, as the Identity Service needs
  to be able to convey to a requesting client that the user is not
  signed in. Note that a separate HasPrimaryAccount() => bool method
  would not suffice here: since the communication is asynchronous, the
  user could always have signed out by the time that the Identity
  Service receives the GetPrimaryAccountId() call.

BUG=683120, 683124
TEST=Install a Chrome extension with the identity and identity.email
permissions in its manifest. Go to chrome://extensions, enable developer mode,
and inspect the background page of the above app. At the JS console that that
brings up, execute:
chrome.identity.getProfileUserInfo((account) => {console.log(account)})
Verify that the printout corresponds to the information of the account
being used for sync.
==========

to

==========
Introduce Identity Service and its initial usage

This CL introduces the Identity Service and converts the implementation
of the chrome.identity.GetProfileUserInfo() extension function to use
the new service. Notable points:

- The Identity Service is embedded in //chrome rather than //content,
  as it needs access to per-Profile classes with //chrome-level
  factories.
- The initial API is simply enough to satisfy the needs of the initial
  consumer. We will build out this API by incrementally converting
  further consumers.
- In the long term, the //components/signin classes on which the
  Identity Service depends will be folded into the Identity Service
  implementation, and their consumers will be converted to consume the
  Identity Service.
- The Identity Service makes use of the existing AccountId Mojo struct.
  It extends that struct to be nullable, as the Identity Service needs
  to be able to convey to a requesting client that the user is not
  signed in. Note that a separate HasPrimaryAccount() => bool method
  would not suffice here: since the communication is asynchronous, the
  user could always have signed out by the time that the Identity
  Service receives the GetPrimaryAccountId() call.

BUG=683120, 683124
TEST=Install a Chrome extension with the identity and identity.email
permissions in its manifest. Go to chrome://extensions, enable developer mode,
and inspect the background page of the above app. At the JS console that that
brings up, execute:
chrome.identity.getProfileUserInfo((account) => {console.log(account)})
Verify that the printout corresponds to the information of the account
being used for sync.

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

[commit-bot: I haz the power, 2017-03-24 13:57:22]

Committed patchset #5 (id:80001) as
https://chromium.googlesource.com/chromium/src/+/b85bd3b039159890285ab7df4bf2...