hard code live remote setting server location

[eakubilo]

Fixes #122.

https://firefox-source-docs.mozilla.org/python/marionette_driver.html
I did two things:

1. I added https://github.com/mozilla/geckodriver to PATH.
2. I hard coded the "services.settings.server" preference (in about:config) to https://firefox.settings.services.mozilla.com/v1".

to explain

1. I didn't see in the installation directions but did anyway to suppress the annoying warning that happens when you run the crawler.
2. Something is passing a development flag down to the web driver, which causes the "services.setting.server" key to have value "data:,#remote-settings-dummy/v1" in about:config. I do not know what causes the dummy url to be the default value of the key, all I presume is overriding it fixes the issue.

With enough investigation we can stumble upon this page which says:

If you open the browser developer tools in a normal nightly browser, and look at that exact portion of the indexedDB, you will notice that this is where all our anti-tracking lists are stored.

To motivate things more, this file is empty with in broken controlled browser.

If we look elsewhere on the same page, we learn this:

If you look at the console of the normal nightly, you'll see that it's very clean:

But our controlled nightly instance has errors, conveniently for us in the RemoteSettingsClient:

The error is especially useful to clue us in on what has happened. The local database is empty, so the client attempts to fetch settings from a sever, but fails since "data:,#remote-settings-dummy/v1" is not a real server. So, when we explicitly assign "services.settings.server" as "https://firefox.settings.services.mozilla.com/v1" in our preferences, we ensure that the local database gets synced with a real target.

With the change, our console looks nice again:

Moreover, the local database is flush, which is what we really care about:

Analysis file:
analysisfile.txt
screenshot of browser:

[Mattm27]

Great work @eakubilo! The urlClassification object looks to be operating properly in the crawl on my end with the updated settings serving location in local-crawler.js. We appreciate the hard work on this, we would love to hear more about your thought process and how you went about diagnosing and eventually solving this problem.

[SebastianZimmeck]

Indeed, well done, @eakubilo!

If you can write up a brief summary, as @Mattm27 mentioned, we would all learn something. You can do so in the issue.