Raise on File.stream's aenter if the file is a dir or doesn't exist

[FasterSpeeding]

Summary

This matches the behaviour seen for URL resources (which happen to be the only other kind where the resource may not exist or may be invalid) and should solve the issue of aiohttp giving off confusing errors on unknown files by erroring before we enter an aiohttp context.

Checklist

• I have run nox and all the pipelines have passed.
• I have made unittests according to the code I have added/modified/deleted.

Related issues

Fixes: #826

[davfsa]

I am not overly happy with this. It does provide a more helpful error, but if people now how to debug python, they should be able to notice the file not found error above the error to send the request.

Additionally, this doesnt guarantee that the file is not deleted or moved after it is opened, which can lead to even more errors.

I would rather just have aiohttp deal with this and not us.

[FasterSpeeding]

I am not overly happy with this. It does provide a more helpful error, but if people now how to debug python, they should be able to notice the file not found error above the error to send the request.

Ok but this just matches the behaviour for URL where if it doesn't exist it'll error before being "read" into, giving a guarantee t that file.__aenter__ will error if a resource doesn't exist instead of making that dependent on whether its a URL or File

Additionally, this doesnt guarantee that the file is not deleted or moved after it is opened, which can lead to even more errors.

It's OS impl detail on whether that even matters anyways: unix systems will keep the file alive until the last application closes it and windows just doesn't let you delete a file if its open in another app; what we might be able to do to handle this is keep the file pointer alive instead of re-opening it once they start reading so all that'd really need to be changed is to keep it open until its finished reading it rather than re-opening it which should be an easy change for threaded file reads at least but idk about process pool file reads so

[FasterSpeeding]

I actually have an impl which keeps the file open for the duration of the context manager for thread based file readers locally already but I don't think the same behaviour can be achieved with a process file reader (well unless you just do something hacky that also opens the file in a thread pool)

Im also not sure what the point of allowing a process pool be used for file reading is (like file reading is blocking IO, not cpu bound work). Kinda seems like unnecessary overhead and complexity unless I'm missing something

[davfsa]

If you think it is worth having, then we can go for it