Remove path='/' from kLibCrosProxyResolveSignalFilter.

Remove path='/', that restricts the sender object path to "/", so that
update_engine can receive signals from the new sender object path.

As of now, LibCrosService in Chrome sends signals from the object path
"/", but this is more like a design shortcoming, as the signal is actually
sent from the LibCrosService object with "/org/chromium/LibCrosService" as
its object path. As part of crosbug.com/18904, we'll fix the sender
object path by changing it from "/" to "/org/chromium/LibCrosService".

Once it's done we could add path='/org/chromium/LibCrosService' to the
match rule, but as long as the interface name and the signal name match,
the sender object path wouldn't matter. After all, senders can set
arbitrary sender object paths, like "/" or "/Whatever".

BUG=chromium-os:18904
TEST=FEATURES=test emerge-x86-alex update_engine. also manually to confirm that the proxy resolution works as before:
- set a bogus proxy in chrome (bogus.corp.google.com:12345)
- request an update (run "update_engine_client --check_for_update")
- look in the update log (/var/log/update_engine.log) and
- see that the updater tried to use the bogus proxy
- the log says:
[0831/111758:INFO:libcurl_http_fetcher.cc(66)] Using proxy: http://bogus.corp.google.com:12345

Change-Id: If92ec53947c717b80203121fc3e60a699a5f5171
Reviewed-on: http://gerrit.chromium.org/gerrit/7001
Tested-by: Satoru Takabayashi <[email protected]>
Reviewed-by: Andrew de los Reyes <[email protected]>

chrome_browser_proxy_resolver.cc

@@ -39,7 +39,6 @@ const char kLibCrosProxyResolveSignalInterface[] =
     LIB_CROS_PROXY_RESOLVE_SIGNAL_INTERFACE;
 const char kLibCrosProxyResolveSignalFilter[] = "type='signal', "
     "interface='" LIB_CROS_PROXY_RESOLVE_SIGNAL_INTERFACE "', "
-    "path='/', "
     "member='" LIB_CROS_PROXY_RESOLVE_NAME "'";
 #undef LIB_CROS_PROXY_RESOLVE_SIGNAL_INTERFACE
 #undef LIB_CROS_PROXY_RESOLVE_NAME