Makes WindowTreeHostMus supply properties directly to window creation

ui/aura/mus/window_tree_host_mus.cc

Index: ui/aura/mus/window_tree_host_mus.cc
diff --git a/ui/aura/mus/window_tree_host_mus.cc b/ui/aura/mus/window_tree_host_mus.cc
index 3fb232b8d427e9082a632cbb360d637f7464d81c..c7d906f65a900e4e2ef37dbc4715a12642b8bbfa 100644
--- a/ui/aura/mus/window_tree_host_mus.cc
+++ b/ui/aura/mus/window_tree_host_mus.cc
@@ -89,7 +89,7 @@ WindowTreeHostMus::WindowTreeHostMus(
     const std::map<std::string, std::vector<uint8_t>>* properties)
     : WindowTreeHostMus(
           static_cast<WindowTreeHostMusDelegate*>(window_tree_client)
-              ->CreateWindowPortForTopLevel(),
+              ->CreateWindowPortForTopLevel(properties),
           window_tree_client,
           display::Screen::GetScreen()->GetPrimaryDisplay().id(),
           properties) {}

[msw, 2016/12/02 00:31:08]

The other constructor re-applies these properties; is that right?
Sorry, I'm a bit confused... not sure if this makes sense.

[sky, 2016/12/02 01:08:43]

Ya, sorry, I agree this is weird. WindowPort is the porting layer introduced for
mus. Each Window has an associated WindowPort. CreateWindowPortForTopLevel()
creates the WindowPort (not the Window) and asks the server to create the
representation of the window on its side. |properties| is supplied to
CreateWindowPortForTopLevel so properties can be passed to the server. The other
WindowTreeHostMus constructor (actually, the superclass) creates the Window with
the WindowPort created from WindowTreeClient. Then the properties are passed
through PropertyConverter and applied to the window.

The old code created the Window first, applied the properties to it, then when
the call to create the window on the server side was called the properties were
extracted from the Window and passed to the server. This meant any properties
not known to PropertyConverter were dropped on the floor. This is bad as some
properties are only useful during initial construction.

[msw, 2016/12/02 01:21:40]

Okay, thanks for the explanation, would a comment here be worthwhile?
(or is there somewhere else that documents this pattern?)