Give the nightly E2E test job a realistic timeout

The Windows legs of the python-nightly matrix run right up against Azure
Pipelines' implicit 60-minute job timeout, so they get cancelled even though the
test suite itself passes. This is what has been showing up as a "flaky" nightly.

Measured on build 161689 (a clean run, setup and cleanup both green):

  py39_windows_mqtt     60.4 min -> CANCELLED
  py39_windows_mqttws   52.9 min -> passed, ~7 minutes of headroom
  the seven linux legs  31.9 - 34.7 min

The cancelled leg had already printed its pytest summary before being killed:

  ========= 74 passed, 33 skipped, 67924 warnings in 3437.00s (0:57:16) =========

So nothing actually failed -- 0 failures, 74 passed -- the job simply ran out of
wall clock during teardown. Whichever Windows leg happens to be slower on the day
is the one that dies, which is why the failure appears to wander between
py39_windows_mqtt and py39_windows_mqttws across runs.

vsts/python-nightly.yaml sets no timeoutInMinutes anywhere, so every job inherits
the 60-minute default. Set 90 minutes on the Test job.

This is a CI-budget fix and is unrelated to the CodeQL change in this PR, but it
has to live on this branch for this PR's own python-nightly check to pass. Happy
to split it into its own PR if preferred.

Author: ewertons

vsts/python-nightly.yaml

@@ -62,6 +62,17 @@ stages:
 - stage: build_and_tests
   jobs:
   - job: 'Test'
+    # The Windows legs of this matrix run right up against Azure Pipelines' implicit
+    # 60-minute job timeout, so they get cancelled mid-run even though the suite
+    # itself passes. Measured in build 161689:
+    #   py39_windows_mqtt     60.4 min -> CANCELLED (pytest had already reported
+    #                                     "74 passed, 33 skipped" in 57:16)
+    #   py39_windows_mqttws   52.9 min -> passed, with only ~7 minutes of headroom
+    #   the seven linux legs  31.9 - 34.7 min
+    # Whichever Windows leg is slower on the day is the one that dies, which is why
+    # the failure appears to wander between py39_windows_mqtt and py39_windows_mqttws.
+    # Give the job a realistic budget instead.
+    timeoutInMinutes: 90
     variables:
       IOTHUB_CONNECTION_STRING: $[stageDependencies.setup.create_iot_hub_and_dps.outputs['createAzureResources.IOTHUB_CONNECTION_STRING']]
       EVENTHUB_CONNECTION_STRING: $[stageDependencies.setup.create_iot_hub_and_dps.outputs['createAzureResources.EVENTHUB_CONNECTION_STRING']]