Unable to open too many DevTools pages due to browser per-host connection limit being exhausted by SSE connections

[DanTup]

Moving this from Dart-Code/Dart-Code#5229.

If you run DevTools and open ~5 tabs for it, you'll find you can't open any more. This appears to be because the SSE connections are tying up the maximum number of connections Chrome allows to a single host.

From my testing of opening many https://echo.websocket.org/.ws pages, I think WebSockets are not counted towards this limit, so the solution may be to migrate the SSE connections to WebSockets. However, I don't know if there may be internal issues with WebSockets that led to SSE being used initially (@kenzieschmoll do you know? there's currently a mix of WS + SSE, so I presume WS must work everywhere now?).

Another option may be to use HTTP2 (so requests can share connections), but it's not clear to me if Dart has a HTTP2 server (I found https://github.com/dart-lang/http2 but it doesn't look like a complete solution?).

[DanTup]

Looking at the SSE client (devtools_app\lib\src\shared\server\server_api_client.dart), the SSE connection is currently used for:

Server -> Frontend

• connectToVm() - used for the server to tell an active DevTools page to connect to a new VM Service URL
• showPage - used for the server to tell DevTools to switch to a specific page
• enableNotifications - used to trigger a prompt to enable notification permissions
• notify() - used to show a browser notification ("DevTools is available in this existing browser window")
• ping() - a simple ping so the server knows DevTools is still open here (so it doesn't try to reconnect it/change page if it's been closed)

Frontend -> Server

• connected - tells the server it is connected to a VM Service URL
• currentPage - tells the server it has changed page
• disconnected - tells the server it has disconnected from a VM Service
• getPreferenceValue - reads a stored preference value
• setPreferenceValue - stores a preference value
• pingResponse - sends a response to a ping

Ignoring the preferences, the other APIs were related to Dart-Code (I'm not sure about IntelliJ - @helin24 ?) spawning DevTools in Chrome (by having the server locate Chrome and decide whether to launch new tabs or try to reuse existing ones, notifying the user). It was done before we had embedded DevTools and when DevTools only worked in Chrome.

While we could migrate those APIs to go via WS, I wonder if there's much value. DevTools is embedded by default now and I believe it works in all browsers. If we were to drop these APIs (from the IDEs, and then later DevTools), the things we would lose are:

• launching in Chrome instead of the default browser when choosing to "Launch DevTools in browser" instead of embedded from the IDEs (or at least VS Code)
• reconnecting external DevTools windows if you stop/restart a debug session (embedded ones would still work because they work by refreshing)
• switching between DevTools pages in external browser when trying to launch another tool (this behaviour is maybe questionnable anyway, if you're using the inspector and launch CPU profiler, would you expect your inspector page to be reused?)
• getting a notification (instead of a new tab) if you launch a DevTools page in external browser when you already have it open

Unfortunately I don't have any stats on embedded vs external use, but perhaps DevTools does (both should have IDE=VSCode, but only embedded versions have embed=true).

@kenzieschmoll @jwren any opinions?