fix: attempt resume on websocket closure with close_code = 1000 in edge cases

[shiftinv]

Summary

This should hopefully fix a spurious websocket quirk introduced in aiohttp 3.9.0, which results in shards fully reconnecting instead of resuming on abrupt connection loss. See aio-libs/aiohttp#8138 and the comment left in the code for more details.
There are several different workarounds for this, this is one of them. It's not pretty, but likely the most reliable one, besides another one I experimented with a while ago which relied on aiohttp internals too much :/

Only cpython 3.10 and earlier is affected, since 3.11.0a6+ uses uvloop's ssl implementation, which doesn't have this particular issue with ssl transport lifecycles.

Some references:

• https://canary.discord.com/channels/808030843078836254/1196843077659283496
• https://canary.discord.com/channels/808030843078836254/1280292681565605939
• https://canary.discord.com/channels/808030843078836254/1219276382648008704
• https://canary.discord.com/channels/808030843078836254/1199231240369352715
• https://canary.discord.com/channels/808030843078836254/942319505915412500/1276306995674087479

Reproduction steps (sort of):

• run an autosharded client
• get the client ws port using bot._get_websocket(shard_id=0).socket.get_extra_info("sockname")
• run sudo tcpkill -i <iface> port <port> (simulating the connection drop by inserting a TCP RST)
• wait for (or cause) some sort of websocket frame to be sent
• notice the shard fully reconnecting instead of resuming

Checklist

• If code changes were made, then they have been tested
  • I have updated the documentation to reflect the changes
  • I have formatted the code properly by running pdm lint
  • I have type-checked the code by running pdm pyright
• This PR fixes an issue
• This PR adds something new (e.g. new method or parameters)
• This PR is a breaking change (e.g. methods or parameters removed/renamed)
• This PR is not a code change (e.g. documentation, README, ...)