PYTHON-1354 do not set timeout to None when calling execute_async in execute_concurrent

[osttra-h-jarrendal]

When timeout is not passed to execute_async, the default timeout=_NOT_SET will use the request_timeout specified in the execution_profile. This is not the same as setting the timeout to None. This will instead result in having no timeout which is not ideal. If this behavior really is wanted, the request_timeout can be set to None in the execution_profile instead.

Bug ticket: https://datastax-oss.atlassian.net/browse/PYTHON-1354

[osttra-h-jarrendal]

There is an issue with the CI build that seems unrelated to the change. Can the build be re-triggered please?

[absurdfarce]

Hey @osttra-h-jarrendal , thanks for the ping? I'm assuming your message above refers to the Travis CI build? If that's the case I don't think re-running the build will address the issue:

==================================== ERRORS ====================================
_________ ERROR at setup of LibevTimerTest.test_multi_timer_validation _________
cls = <class 'tests.unit.io.test_libevreactor.LibevTimerTest'>
    @classmethod
    @noop_if_monkey_patched
    def setUpClass(cls):
        if LibevConnection is None:
>           raise unittest.SkipTest('libev does not appear to be installed correctly')
E           twisted.trial.unittest.SkipTest: libev does not appear to be installed correctly
../../../tests/unit/io/test_libevreactor.py:100: SkipTest
___________ ERROR at setup of LibevTimerTest.test_timer_cancellation ___________
cls = <class 'tests.unit.io.test_libevreactor.LibevTimerTest'>
    @classmethod
    @noop_if_monkey_patched
    def setUpClass(cls):
        if LibevConnection is None:
>           raise unittest.SkipTest('libev does not appear to be installed correctly')
E           twisted.trial.unittest.SkipTest: libev does not appear to be installed correctly
../../../tests/unit/io/test_libevreactor.py:100: SkipTest
=============================== warnings summary ===============================

It looks like libev isn't being installed on those runners, which is a bit strange since we don't explicitly install it in our config. I'll take a quick look and see if this is an easy fix but we'll very likely be retiring Travis completely now that we've moved this project to the Apache Software Foundation.

We'll be setting up a new CI infra for this project there but that will take a bit of time to get done. In the interim the best answer is probably to run a test build on our old Jenkins infrastructure. I just tried to kick that off for you but it looks like that's also borked, apparently as a side effect of the move. I'm working on getting all of that resolved but given the holidays it might take a while.