Blazor-SignalR configuration updates

[guardrex]

Fixes #26465

Brennan, this is a bit drafty at the moment, but it's probably worth sorting out the SignalR settings for this before I copy content for multiple versions of the content ... and even across docs, since we probably need these updates for the hosted WASM case, too.

This PR is mostly about addressing Javier's ask at ...

Connection disconnected with error 'Error: Server timeout elapsed without receiving a message from the server.'.
dotnet/aspnetcore#42778 (comment)

There are several permutations of the configuration. Ultimately, I'm trying to cover both hosting models, WebSockets (primary) and Long Polling (fallback), and server/client config for when latency is spawning the reconnection UI.

The critical piece is Lines 754-828 in the Host and Deploy > Server article where the settings to avoid timeouts are covered. After that content is corrected, I'll flesh out a version of it for the WASM article (as a hosted WASM scenario).

I couldn't quite tell from the issue and API exactly which settings are required where. I probably need to prune one or more of them.

Since it might be easier to just look at that bit right here in a comment instead of sorting through all of the doc churn, here it is. If you let me know for this bit what's right, what's wrong, and what's iNsAnE 😵😄 ... I'll update from there and then ping you back later for a full review of the PR.

Recommendations for global deployments to geographical data centers:

* Deploy the app to the regions where most of the users reside.
* Take into consideration the increased latency for traffic across continents.
* For Azure hosting, use the [Azure SignalR Service](#azure-signalr-service).

If a deployed app frequently displays the reconnection UI due to ping timeouts caused by Internet latency, lengthen the server and client timeouts:

* **Server**

At least double the maximum roundtrip time expected between the client and the server. Test, monitor, and revise the timeouts as needed. For the SignalR hub, set the <xref:Microsoft.AspNetCore.SignalR.HubOptions.ClientTimeoutInterval> (default: 30 seconds), <xref:Microsoft.AspNetCore.SignalR.HubOptions.HandshakeTimeout> (default: 15 seconds), and <xref:Microsoft.AspNetCore.SignalR.HubOptions.KeepAliveInterval> (default: 15 seconds).

For a Blazor Server app in `Program.cs`:

```csharp
builder.Services.AddServerSideBlazor()
    .AddHubOptions(options =>
        {
            options.ClientTimeoutInterval = TimeSpan.FromSeconds(60);
            options.HandshakeTimeout = TimeSpan.FromSeconds(30);
            options.KeepAliveInterval = TimeSpan.FromSeconds(30);
    });
```

For more information, see <xref:blazor/fundamentals/signalr#circuit-handler-options-for-blazor-server-apps>.

* **Client**

Typically, double the value used for the server's <xref:Microsoft.AspNetCore.SignalR.HubOptions.KeepAliveInterval> to set the timeout for the client server timeout (`serverTimeoutInMilliseconds`, default: 30,000 milliseconds). Match the keep alive interval (`keepAliveIntervalInMilliseconds`, default: 15,000 milliseconds) to the server's <xref:Microsoft.AspNetCore.SignalR.HubOptions.KeepAliveInterval>. To configure the client, set the `autostart` attribute to `false` and configure the SignalR options in [`Blazor.start`](xref:blazor/fundamentals/startup):

```html
<script src="_framework/blazor.server.js" autostart="false"></script>
<script>
  Blazor.start({
    configureSignalR: function (builder) {
      builder.serverTimeoutInMilliseconds = 60000;
      builder.keepAliveIntervalInMilliseconds = 30000;
    }
  });
</script>
```

For more information, see <xref:blazor/fundamentals/signalr#configure-signalr-server-timeout-and-keep-alive-on-the-client>.

Those two "For more info ..." cross-links will go back to the Fundamentals > SignalR topic, where the settings are covered in a more general way, not specifically for ping timeout/latency problems. The fundamentals topic will also have cross-links to this Host and deploy coverage.

[BrennanConroy]

My only minor complaint is that the keep alive interval isn't directly related to the problem and doesn't necessarily need to be changed. If your issue is due to timeouts, then the timeouts can be increased and the keep alive intervals can stay the same. If you do change them then they should be 50% or less of the timeout values, and maybe you do want to change them at the same time as you increase the timeouts in order to reduce bandwidth.

[guardrex]

Thanks @BrennanConroy ... I'll complete the work on this within the next few days ... probably early next week, including updates to address your feedback using your language. I'll ping u back.

[guardrex]

NOTE: NO rush on this. Let's take it up next week if you like, @BrennanConroy. I needed to wait on further JS interop (new API) just a bit longer for another PR that I was going to work this morning. Since I'm pushing that off to Monday, I was able to set it all up this morning.

To avoid serious 👁️ strain, here are the two sections now (one for Blazor Server Host and Deploy, one for hosted Blazor WebAssembly Host and Deploy). I paste them in below and provide the internal review topic links direct to the sections. Removed from this comment!

I DO need to edit it all again, so don't be surprised by a spelling error or other NITs 😈 trying to sneak into it. Done!

The base coverage in the Blazor > Fundamentals > SignalR topic didn't change because that's just basic coverage on how to change the properties, no specific guidance is present there.

I'm not going to beautify 🌷 the following content paste-ins. I'm rapidly running out of time this week and a bit exhausted and in need of a weekend break 😩. I'm just going to paste the content directly from the diff. Removed from this comment!

If the following is right ... or can be fixed up with a little more feedback ... I won't need further review of this PR. What's below is the meat 🍖 for the whole PR. The rest is just nits, bits, cross-links, and fluff. Removed from this comment!

• Internal Review Topic (Blazor Server bit) (links to section)
• Internal Review Topic (hosted WASM bit) (links to section)

[guardrex]

@BrennanConroy ... This looks good. I used your language. I don't think it requires further review. I'll take community feedback on it going forward.