connection often times out on `test_download` and `test_get_download_normalization_process_handler`

[gwarmstrong]

Something potentially gnarly, but likely out of the scope of this PR... I ran ea536f3's build twice (this one), and it passed the first time but failed on the two "download" tests (test_download and test_get_download_normalization_process_handler) when run again.

Since these failures were both caused by AssertionError: Async operation timed out after 10 seconds, it seems like this is an intermittent error due to network problems (???). Not sure how best to handle this, but as a brute-force solution using travis_retry with the python tests might work.

You're right, this has been a recurrent problem I've noticed in the past couple weeks. I think there are a couple things we can do to try to reduce this.

• Increase the timeout limit in the line below:
  

  LabControl/labcontrol/gui/testing.py

  Line 71 in 1427ad1

  return self.wait(timeout=10)

• add retry functionality within the test, e.g. something like this:

class TestDownloadLibraryPrepShotgunProcessHandler(TestHandlerBase):
    def test_download(self):
        retries = 0
        response = None
        while retries < 5:
            try:
                response = self.get(
                    '/process/library_prep_shotgun/%d/echo_pick_list' % 1)
            except AssertionError:
                print("Error downloading on try {}.".format(retries))
            else:
                break
        if response is None:
           raise AssertionError("Async operation timed out after maximum number of retries.")

        self.assertNotEqual(response.body, '')
        self.assertTrue(response.body.startswith(
            b'Sample ID\tSource Plate Name\t'))
        self.assertEqual(response.headers['Content-Disposition'],
                         "attachment; filename=2017-10-25_"
                         "Test_compressed_gDNA_plates_1-4_indices.txt")

Originally posted by @gwarmstrong in #585 (comment)

[gwarmstrong]

It may also be useful to do something like

build_number = 0
del build_number

in labcontrol/__init__.py or something like that, then this can be incremented (akin to the build_number parameter in conda-forge builds) to have some arbitrary parameter to change to restart the CI build.