Update requirements and CI for PyQt6.7

[toofar]

(This is on top of #8173, so ignore the first two commits if they are still present.)

This is the usual "add support for new Qt/PyQt version" change that normally happens in the background where the dripping pipes and greasy rags are. I'm raising this PR for visibility in case anyone has an opinion on how to deal with the macOS WebEngine binaries not being available yet.

See commit ce562b7 for the PyQt6.7 related updates to requirements files and CI definitions for the actual version upgrade.

Upgrading to Qt6.7 doesn't seem to have had any user visible impact (apart from the Vulkan backend not working, and primary selection not being filled from the copy action anymore), which is a relief. It did cause some hard to debug issues in the tests, but hopefully that's the last we'll hear of that. (Also looks like there is one issue with IPC sockets closing differently on application shutdown on windows that still needs to be resolved, in the tests).

We've wanted to get a new release out with Qt6.7 for a while. Unfortunately the corresponding PyQt release has been delayed for a longer time than usual, but it's available now! Which means we can cut a new release! BUT, as mentioned in the announce email there are no binaries available for macOS. It seems PyQt is waiting on this support request to PyPI: pypi/support#3949

As I see it our options are:

1. delay the release until the PyQt6.7 WebEngine binaries for macOS are available
2. release now¹ with macOS shipping with Qt 6.6 - and then make a new one when the binaries become available so mac users can get a new chromium base
3. release now¹ but finagle the release job so it pulls QtWebEngine from riverbank's PyPI servers, as suggested in their email

Footnotes

1. "now" probably means some time next week, we might want to add a fix for https://github.com/qutebrowser/qutebrowser/issues/8170 in too ↩ ↩²

[The-Compiler]

Ugh. I thought it would be easy and we'd just need to set commands_pre for tox. Turns out it wasn't easy, because installing dependencies happens before that....

I attempted the required finagling with requirement files and tox.ini and mkvenv.py and whatnot to get this to work.

On a second thought, I wonder if I could just have dumped --extra-index-url https://www.riverbankcomputing.com/pypi/simple/ into the requirements files, because pip should support this in theory.

[toofar]

✔️ cool, I'm okay with that approach. I think this is a safe use of --extra-index-url since the riverbank pypi is a pretty tightly controlled repo, and I think they use pre-release builds for experimental stuff (we've been warned a lot about --extra-index-url at work but that's regarding someone shadowing internal libraries on the public pypi repo, not really applicable here).

Regarding the failure on windows, I got as far as seeing that it looks like a socket "times out" in like 200ms when the timeout is set to 5s. I was going to compare the logs for a single test on windows to linux and see if I can spot a difference. I did install a nightly from this branch in a VM and it shut down fine at least, didn't check with userscripts because I forgot they aren't bundled :)

Eg regarding the timing there are logs like this (wait, is that the ID of the ephemeral socket for a client connection or the listening one for the server?):

02:35:05.191 DEBUG    ipc        ipc:handle_connection:255 Client connected (socket 0x1d2da57d3b0).
02:35:05.223 ERROR    ipc        ipc:on_timeout:394 IPC connection timed out (socket 0x1d2da57d3b0).

Edit: heres the nightly built off of this branch, it works!:

[The-Compiler]

Taking the IPC timeout thing to #8191. I'm taking a look and need a place for notes.