Why shouldn't TetherHostFetcher use just "MAGIC_TETHER_HOST == kEnabled"?

Re: comment #3: Essentially, it should use that. However, this should be encapsulated by the upcoming MultiDeviceSetup API, so I'm waiting on implementing this fix.

Jeremy's going to take this bug over while I work on another task.

What needs to be done:
(1) TetherService already has access to MultiDeviceSetupClient. When it creates TetherHostFetcher, pass MultiDeviceSetupClient to its constructor.
(2) Within TetherHostFetcherImpl::CacheCurrentTetherHosts(), use MultiDeviceSetupClient::GetHostStatus() to grab the current host.
(3) If there is no current host, make |current_remote_device_list_| an empty list.
(3) If there is a current host, set |current_remote_device_list_| to be that one host (only one host is possible per account with the new flag on).

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5e7a75eaa5efba5398758b1b90a02c96965c82df

commit 5e7a75eaa5efba5398758b1b90a02c96965c82df
Author: Jeremy Klein <jlklein@google.com>
Date: Tue Aug 21 03:03:13 2018

Use MultideviceSetupClient to fetch tether hosts.

This will limit Magic Tether hosts to devices that have gone through
Better Together Setup.

Bug:  870072 
Change-Id: I9fe120f4b8d07f831ebe84aeb28267ff379f2e82
Reviewed-on: https://chromium-review.googlesource.com/1180473
Reviewed-by: Kyle Horimoto <khorimoto@chromium.org>
Commit-Queue: Jeremy Klein <jlklein@chromium.org>
Cr-Commit-Position: refs/heads/master@{#584617}
[modify] https://crrev.com/5e7a75eaa5efba5398758b1b90a02c96965c82df/chrome/browser/chromeos/tether/tether_service.cc
[modify] https://crrev.com/5e7a75eaa5efba5398758b1b90a02c96965c82df/chrome/browser/chromeos/tether/tether_service_unittest.cc
[modify] https://crrev.com/5e7a75eaa5efba5398758b1b90a02c96965c82df/chromeos/components/tether/BUILD.gn
[modify] https://crrev.com/5e7a75eaa5efba5398758b1b90a02c96965c82df/chromeos/components/tether/tether_host_fetcher_impl.cc
[modify] https://crrev.com/5e7a75eaa5efba5398758b1b90a02c96965c82df/chromeos/components/tether/tether_host_fetcher_impl.h
[modify] https://crrev.com/5e7a75eaa5efba5398758b1b90a02c96965c82df/chromeos/components/tether/tether_host_fetcher_impl_unittest.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5e84dd0eb5823863e459e1defc06204ad72fb55c

commit 5e84dd0eb5823863e459e1defc06204ad72fb55c
Author: Jeremy Klein <jlklein@google.com>
Date: Tue Aug 21 03:41:36 2018

Always append sms experiment params to flag-passed urls.

The PWA install API always needs the experiment URL params for now,
but the service worker logic can never have those or stuff breaks.
This change resolves that discrepancy.

Also switch the staging url to point to one that doesn't require
uberproxy because the PWA install API doesn't play well with URLs
that have redirects. This still points to the same actual Messages
code, though.

R=azeemarshad@chromium.org

Bug:  870072 
Change-Id: I23f6f0c4d375f2301cfd1b8efb94d36bf88581cf
Reviewed-on: https://chromium-review.googlesource.com/1182868
Reviewed-by: Ryan Hansberry <hansberry@chromium.org>
Commit-Queue: Jeremy Klein <jlklein@chromium.org>
Cr-Commit-Position: refs/heads/master@{#584639}
[modify] https://crrev.com/5e84dd0eb5823863e459e1defc06204ad72fb55c/chrome/browser/chromeos/android_sms/android_sms_urls.cc

Obviously that last CL was tied to the wrong bug. Please ignore it :-p.