GitLab

Based on a discussion with Chrome Sydney C++, it is preferable not to
have fine-grained Keyed services, and instead use an approach like the
WebAppsPlatform does.  Diagram in go/borealis-arch.

Reasons given were:
1) Complicated crashes for getting keyed service per Profile-type
   (incognito OTR. guest, login-porile see
   http://go/chromium-profile-types)
2) Two-pass shutdown but no symmetric Two-pass Setup (circular deps)
3) The base classes API which you don't own (inability to control it)
4) A dependent KeyedService may enforce the creation of the dependee
   KeyedService for the unwanted profile type
5) 2 .cc + 2 .h files for each service (instead of simple one .cc + .h
   pair)
6) Simplicity vs overkill

Bug: b/170596931
Change-Id: Iee61e29b5ac29abf1ba9b00b4939ffea65bd8be1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2465887
Commit-Queue: Nic Hollingum <hollingum@google.com>
Reviewed-by: Nancy Wang <nancylingwang@google.com>
Reviewed-by: Nancy Wang <nancylingwang@chromium.org>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Reviewed-by: Daniel Ng <danielng@google.com>
Cr-Commit-Position: refs/heads/master@{#817213}