Currently, asyncio.wait_for(fut), upon reaching the timeout deadline,
cancels the future and returns immediately.  This is problematic for
when *fut* is a Task, because it will be left running for an arbitrary
amount of time.  This behavior is iself surprising and may lead to
related bugs such as the one described in bpo-33638:

    condition = asyncio.Condition()
    async with condition:
        await asyncio.wait_for(condition.wait(), timeout=0.5)

Currently, instead of raising a TimeoutError, the above code will fail
with `RuntimeError: cannot wait on un-acquired lock`, because
`__aexit__` is reached _before_ `condition.wait()` finishes its
cancellation and re-acquires the condition lock.

To resolve this, make `wait_for` await for the task cancellation.
The tradeoff here is that the `timeout` promise may be broken if the
task decides to handle its cancellation in a slow way.  This represents
a behavior change and should probably not be back-patched to 3.6 and
earlier.
(cherry picked from commit e2b340a)

Co-authored-by: Elvis Pranskevichus <elvis@magic.io>

When I was fixing bpo-32751 back in pythonGH-7216 I missed the case when
*timeout* is zero or negative.  This takes care of that.

Props to @aaliddell for noticing the inconsistency.

… 0 (#21895)

When I was fixing bpo-32751 back in GH-7216 I missed the case when
*timeout* is zero or negative.  This takes care of that.

Props to @aaliddell for noticing the inconsistency.

… 0 (pythonGH-21895)

When I was fixing bpo-32751 back in pythonGH-7216 I missed the case when
*timeout* is zero or negative.  This takes care of that.

Props to @aaliddell for noticing the inconsistency.
(cherry picked from commit c517fc7)

Co-authored-by: Elvis Pranskevichus <elvis@magic.io>

… 0 (GH-21895) (GH-21963)

When I was fixing bpo-32751 back in GH-7216 I missed the case when
*timeout* is zero or negative.  This takes care of that.

Props to @aaliddell for noticing the inconsistency.
(cherry picked from commit c517fc7)

Co-authored-by: Elvis Pranskevichus <elvis@magic.io>

…out <= 0 (pythonGH-21895)

When I was fixing bpo-32751 back in pythonGH-7216 I missed the case when
*timeout* is zero or negative.  This takes care of that.

Props to @aaliddell for noticing the inconsistency..
(cherry picked from commit c517fc7)

Co-authored-by: Elvis Pranskevichus <elvis@magic.io>

…out <= 0 (pythonGH-21895)

When I was fixing bpo-32751 back in pythonGH-7216 I missed the case when
*timeout* is zero or negative.  This takes care of that.

Props to @aaliddell for noticing the inconsistency..
(cherry picked from commit c517fc7)

…out <= 0 (GH-21895) (#21967)

When I was fixing bpo-32751 back in GH-7216 I missed the case when
*timeout* is zero or negative.  This takes care of that.

Props to @aaliddell for noticing the inconsistency..
(cherry picked from commit c517fc7)

… 0 (python#21895)

When I was fixing bpo-32751 back in pythonGH-7216 I missed the case when
*timeout* is zero or negative.  This takes care of that.

Props to @aaliddell for noticing the inconsistency.