AsyncResolver does not use the passed `loop` argument on 3.11 and 3.12 branches due to bad cherry-pick merge

[PLPeeters]

Describe the bug

There seems to be a backport issue in the 3.11 and 3.12 branches. The loop argument is not passed to aiodns.DNSResolver despite this being the case on the master branch, leading to unexpected bugs when it is used.

master:

https://github.com/aio-libs/aiohttp/blob/master/aiohttp/resolver.py#L87-L91

3.11:

https://github.com/aio-libs/aiohttp/blob/3.11/aiohttp/resolver.py#L87-L96

3.12:

https://github.com/aio-libs/aiohttp/blob/3.12/aiohttp/resolver.py#L87-L96

The root causes is cherry-pick commit 17af047, where the AsyncResolver.__init__ changes were incorrectly merged from d26f16c, missing that loop had been removed as an explicit argument.

To Reproduce

N/A

Expected behavior

Code matches what is on master, using the passed-in loop.

Logs/tracebacks

N/A

Python Version

N/A

aiohttp Version

3.11/3.12

multidict Version

N/A

propcache Version

N/A

yarl Version

N/A

OS

N/A

Related component

Client

Additional context

No response

Code of Conduct

• I agree to follow the aio-libs Code of Conduct

[webknjaz]

#3580 dropped passing loops explicitly in many places.

[PLPeeters]

@webknjaz Yes, but it's still broken in the 3.11/3.12 branches as the loop argument is still there but not passed to aiodns.DNSResolver or used elsewhere in the constructor.

[bdraco]

Thanks for raising this! Could you share a bit more about your use case so we can better understand why this change is needed in the stable branches?

[bdraco]

Looks like it breaks downstream tests https://github.com/home-assistant/core/actions/runs/15196589891/job/42742754688?pr=145358

[PLPeeters]

I ended up refactoring to initialise everything only once the loop is running, which fixed it in the meantime. Still great to see a fix though, it could definitely avoid surprises for other people down the line!