MD Settings: Elim SettingsSubpageBrowsertest and SettingsPageVisibility

chrome/browser/resources/settings/settings_main/settings_main.js

Index: chrome/browser/resources/settings/settings_main/settings_main.js
diff --git a/chrome/browser/resources/settings/settings_main/settings_main.js b/chrome/browser/resources/settings/settings_main/settings_main.js
index 0e43c54e5ec73b337807de8253e9059c24bed270..4a2dfc25d5bece549923f462cccd84fbf5d6ac1c 100644
--- a/chrome/browser/resources/settings/settings_main/settings_main.js
+++ b/chrome/browser/resources/settings/settings_main/settings_main.js
@@ -71,17 +71,10 @@ Polymer({
     },
 
     /**
-     * Dictionary defining page visibility.
-     * @type {!GuestModePageVisibility}
+     * Dictionary defining page visibility. Controlled by settings-ui.
+     * @type {!PageVisibility|undefined}
      */
-    pageVisibility: {
-      type: Object,
-      value: function() {
-        return {};
-      },
-    },
-
-    showAndroidApps: Boolean,
+    pageVisibility: Object,

[dpapad, 2017/05/01 21:02:22]

Can you run tryjobs? I am expecting that there might be some more fixes to be
made because some tests might fail. For example
https://cs.chromium.org/chromium/src/chrome/test/data/webui/settings/settings....

The previous code ensured that |pageVisibility| is initialized, even if you only
create a settings-main element (without a settings-ui parent), such that all
bindings are executing. The new code leaves pageVisibility undefined which might
affect those tests.

[stevenjb, 2017/05/01 23:42:58]

Ah, I thought I ran all tests locally, but it looks like CrSettingsMainPageTest
is disabled. 

Testing with --gtest_also_run_disabled_tests reveals that test is broken on ToT
and probably has been for a while. I don't see how loading settings-main without
settings-ui would work given all of our prefs dependencies.

I'll "fix" settings_main_test.js, but frankly I don't know whether fixing the
test is worth the effort.

[dpapad, 2017/05/01 23:56:34]

If the test is disabled, I don't think you have to fix it as part of this CL.
I've seen this pattern a few times now:

1) Test is flaky.
2) Sheriff disables flaky test.
3) Time passes, test remains disabled while code changes.
4) Someone starts looking into re-enabling the test, only to find out that the
test is no longer flaky, it fails consistently instead (the underlying flakiness
root cause might still be there though).

   },
 
   /** @override */