Migrate extension notifications to the new NotificationDisplayService

chrome/browser/notifications/platform_notification_service_unittest.cc

Index: chrome/browser/notifications/platform_notification_service_unittest.cc
diff --git a/chrome/browser/notifications/platform_notification_service_unittest.cc b/chrome/browser/notifications/platform_notification_service_unittest.cc
index 8ca62641ad7d84271c4596ecd3745cda9258a478..800531c849584ce1cfc3229d8dc0d941e7cc7627 100644
--- a/chrome/browser/notifications/platform_notification_service_unittest.cc
+++ b/chrome/browser/notifications/platform_notification_service_unittest.cc
@@ -96,6 +96,8 @@ class PlatformNotificationServiceTest : public testing::Test {
     std::unique_ptr<NotificationPlatformBridge> notification_bridge =
         base::MakeUnique<StubNotificationPlatformBridge>();
 
+    // TODO(peter): These tests should use the NotificationDisplayService, which

[Miguel Garcia, 2017/02/21 10:56:44]

I'd like to discuss this offline (and will not block the CL) I kind of like the
idea of testing the whole PlatformNotificationService -> Bridge since (as you
know) I consider the bridge and the display service very close together (they
are not the same class because the latter needs to be a singleton while the
former is keyed by profile).

[Peter Beverloo, 2017/02/21 17:23:50]

Sure. In my mind, NotificationDisplayService will provide basic functionality
(e.g. attaching handlers), with the {Native,MessageCenter}DisplayServices
extending it for targeted functionality. The Stub implementation would use the
common functionality too, so we don't actually lose any test coverage.

+    // will allow the StubNotificationPlatformBridge to be removed.
     TestingBrowserProcess::GetGlobal()->SetNotificationUIManager(
         std::move(ui_manager));
     TestingBrowserProcess::GetGlobal()->SetNotificationPlatformBridge(