Changes

• Replaces theunload event withpagehide for sending disconnect beacon from the Blazor client to the server.
• Adds a new beacon message that gets sent from the client when thevisibilitychange event fires on the document.
  • The message payload contains the circuit ID and the new page visibility state.
  • The server stores aPageHiddenAt timestamp of the last change to thehidden state for the session.
  • The timestamp is stored on the currentCircuitHost instance for the session.
  • The server sets the timestamp to null when receiving a beacon with thevisible state. Null value indicates that the page is currently visible and active (as far as the server knows).
• Adds a new resource optimization path inCircuitRegistry.DisconnectAsync (which is called when the SignalR connection breaks).
  • If the page has beenrecently hidden and then the SignalR connection broke, we terminate and dispose the circuit data immediately instead of moving it to theCircuitRegistry.DisconnectedCircuits memory cache (and later into the persistent state storage).

Motivation

We replace theunload event withpagehide because the two should fire in (practically) the same situations but the latter is not deprecated and does not cause warnings for the users.

Reasoning behind the visibility-based optimization is as such:

• Thevisibilitychange event is the only one that fires somewhat reliably on mobile devices, in particular when switching tabs in the browser, switching to another app, or going to the home screen.
• In these situations, the tab with the Blazor app (or the entire browser) is often discarded
  and no other events are processed.
• From the server's point of view, this manifests as such: 1) the server receives the visbility change beacon with thehidden state, 2) depending on the timeout settings, the server recognizes at some point that the SignalR connection has disconnected.
• Previously, unless we received the disconnect beacon (based on theunload/pagehide event), we would move the disconnected circuit into theDisconnectedCircuits memory cache, and later into the persistent state storage. This is wasteful for the mobile scenarios described above as circuits from closed/discarded tabs would never be restored anyway.
• However, there are other browser-side optimizations (particularly on desktop) such as background tab freezing or throttling that might lead to the SignalR connection breaking while the page was hidden. In these situations we don't want to dispose the circuits prematurely because they may be restored when the user switches back to the Blazor tab. For this reason, the PR implementation disposes only circuits forrecently hidden tabs as these optimizations typically kick in after some time.

Risks

1. By adding the visibility change beacon, we are increasing traffic and use some additional server resources.
2. On mobile this change can help significantly. However, on desktop, this does not help much because there thepagehide event fires mostly in the same situations as thevisibilitychange - taking into account only situations where we actuallywant to dispose the circuit (closing the tab, navigating away, hard refresh, closing the browser).
3. Inevitably, there is a scenario which we make worse: user switches tabs (but the Blazor app is still loaded and communicates with server), then the device loses network connection. Previously, we would move the circuit intoDisconnectedCircuits, now we terminate and dispose it (because the server sees the same order of events as e.g. in the mobile app switch scenario) even though the circuit would be eligible for restoration when the device regains network connection and the user foregrounds the Blazor tab.

Questions

1. Do we want the time threshold, i.e. only dispose circuits forrecently hidden pages? If yes, how should we set the threshold? Should it be configurable e.g. viaCircuitOptions? What should be the default value? Or, should we compute it based on someHubOptions value (e.g. the client timeout)?
2. More generally, should this be opt-in or opt-out? How?
3. Is there a client-side configuration for this that we want to expose?

Fixes#54793