Allow timeout to work when reading with nowait

[Dreamsorcerer]

(Note this depends on and extends #5853)

When reading in a loop while the buffer is being constantly filled, the timeout does not work as there are no calls to _wait() where the timer is used.

I don't know if this edge case is enough to be worried about, but have put together an initial attempt at fixing it. I'm not sure if this is really the right solution, but can atleast be used as as a discussion on ways to improve this.

This can't be backported as this changes the public API (one of the functions is now async).

Related #5851.

[asvetlov]

def read_nowait() -> async def read_nowait() signature change is not backward compatible.

Honestly, I'm not sure if nowait read should handle timeouts; it is a nonblocking call by definition.

[webknjaz]

This won't make it into the 3.8 release stream. Turning it into a draft.

[Dreamsorcerer]

OK, after looking at it some more, I realised the timer I was using to fix this was just raising TimeoutError in the __enter__. It's unlikely that the inner loop will ever take long enough to block the event loop too long. So, I've just copied that raise logic to a new method and called it directly. There's no need to make anything async now.

[codecov[bot]]

Codecov Report

Merging #5854 (5b688d9) into master (a5d6418) will increase coverage by 0.00%. The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master    #5854   +/-   ##
=======================================
  Coverage   97.31%   97.31%           
=======================================
  Files         107      107           
  Lines       31488    31507   +19     
  Branches     3938     3941    +3     
=======================================
+ Hits        30642    30661   +19     
  Misses        643      643           
  Partials      203      203           

Flag	Coverage Δ
CI-GHA	97.22% <100.00%> (+<0.01%)	:arrow_up:
OS-Linux	96.88% <100.00%> (+<0.01%)	:arrow_up:
OS-Windows	95.34% <100.00%> (+<0.01%)	:arrow_up:
OS-macOS	96.48% <100.00%> (+<0.01%)	:arrow_up:
Py-3.10.11	96.99% <100.00%> (+<0.01%)	:arrow_up:
Py-3.11.0	96.42% <100.00%> (+<0.01%)	:arrow_up:
Py-3.7.16	96.70% <100.00%> (+<0.01%)	:arrow_up:
Py-3.7.9	95.21% <100.00%> (+<0.01%)	:arrow_up:
Py-3.8.10	95.13% <100.00%> (+<0.01%)	:arrow_up:
Py-3.8.16	96.61% <100.00%> (+<0.01%)	:arrow_up:
Py-3.9.13	95.12% <96.00%> (+<0.01%)	:arrow_up:
Py-3.9.16	96.64% <96.00%> (-0.01%)	:arrow_down:
Py-pypy7.3.11	94.12% <100.00%> (+<0.01%)	:arrow_up:
VM-macos	96.48% <100.00%> (+<0.01%)	:arrow_up:
VM-ubuntu	96.88% <100.00%> (+<0.01%)	:arrow_up:
VM-windows	95.34% <100.00%> (+<0.01%)	:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
aiohttp/helpers.py	95.12% <100.00%> (+0.02%)	:arrow_up:
aiohttp/streams.py	97.46% <100.00%> (-0.01%)	:arrow_down:
tests/test_client_functional.py	98.52% <100.00%> (+0.01%)	:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

[patchback[bot]]

Backport to 3.9: 💔 cherry-picking failed — conflicts found

❌ Failed to cleanly apply 80e2bde149e12754e8caa9d5380f960e16f7b9e3 on top of patchback/backports/3.9/80e2bde149e12754e8caa9d5380f960e16f7b9e3/pr-5854

Backporting merged PR #5854 into master

1. Ensure you have a local repo clone of your fork. Unless you cloned it from the upstream, this would be your origin remote.
2. Make sure you have an upstream repo added as a remote too. In these instructions you'll refer to it by the name upstream. If you don't have it, here's how you can add it:

   $ git remote add upstream https://github.com/aio-libs/aiohttp.git
   

3. Ensure you have the latest copy of upstream and prepare a branch that will hold the backported code:

   $ git fetch upstream
   $ git checkout -b patchback/backports/3.9/80e2bde149e12754e8caa9d5380f960e16f7b9e3/pr-5854 upstream/3.9
   

4. Now, cherry-pick PR #5854 contents into that branch:

   $ git cherry-pick -x 80e2bde149e12754e8caa9d5380f960e16f7b9e3
   

   If it'll yell at you with something like fatal: Commit 80e2bde149e12754e8caa9d5380f960e16f7b9e3 is a merge but no -m option was given., add -m 1 as follows instead:

   $ git cherry-pick -m1 -x 80e2bde149e12754e8caa9d5380f960e16f7b9e3
   

5. At this point, you'll probably encounter some merge conflicts. You must resolve them in to preserve the patch from PR #5854 as close to the original as possible.
6. Push this branch to your fork on GitHub:

   $ git push origin patchback/backports/3.9/80e2bde149e12754e8caa9d5380f960e16f7b9e3/pr-5854
   

7. Create a PR, ensure that the CI is green. If it's not — update it so that the tests and any other checks pass. This is it! Now relax and wait for the maintainers to process your pull request when they have some cycles to do reviews. Don't worry — they'll tell you if any improvements are necessary when the time comes!

🤖 @patchback I'm built with octomachinery and my source is open — https://github.com/sanitizers/patchback-github-app.