Improve Blazor reconnection experience.

[NTaylorMullen]

• Updated text of reconnect dialog to be more clear.
• Added user feedback to the Retry event button click. The current flow is Attempting to reconnect -> Failed to reconnect ... [Retry] -> Click Retry -> Attempting to reconnect.
• Found that in cases where the server went away entirely the reconnect event would through unexpectedly preventing the reconnect display from handling a failed reconnect. Added a separate error flow to understand when the server went away/could not start a SignalR connection to.
• Could not find a great way to add tests for this scenario.
• Fixed all issue requirements except for the last bullet point about auto-reloading. The suggested approach would break development experiences; therefore, going to do a follow up if a better experience can be suggested/is viable.
• One big issue that still exists is when the circuit gets forgotten or the server restarts entirely. We end up successfully connecting to the server but circuit connection fails resulting in a fast response failure to reconnect (shown in the end of the gif below). However, we do not let the user know that reconnect's are no longer feasible. That would be addressed by something like: Reconnection enhancements #12442 (comment)

This is of me stopping the server, clicking retry a few times, restarting the server, clicking retry, reloading the page.

Addresses #12442

[NTaylorMullen]

SignalR throws if you attempt to reconnect like this while the connection is not connected. This prevented the reconnect display from properly handling scenarios where the server went away.

[NTaylorMullen]

Actually, can't remove this entirely. It breaks the expectation of calling code, i.e. in DefaultReconnectionHandler it expects:

        // reconnectCallback will asynchronously return:
        // - true to mean success
        // - false to mean we reached the server, but it rejected the connection (e.g., unknown circuit ID)
        // - exception to mean we didn't reach the server (this can be sync or async)

In a way it makes sense. Basically, we need to have 3 different return values and instead of having an enum the previous design utilized exceptions. I'll revert this change in my next change for this experience but enable the reconnect display to handle exceptions so the UI doesn't die.

[rynowak]

One big issue that still exists is when the circuit gets forgotten or the server restarts entirely. We end up successfully connecting to the server but circuit connection fails resulting in a fast response failure to reconnect (shown in the end of the gif below). However, we do not let the user know that reconnect's are no longer feasible. That would be addressed by something like: #12442 (comment)

What's the problem with this precisely? We know that ConnectCircuit fails because it will return false. Is the problem that we have to way to show differnt UI when that happens?

[rynowak]

I think these changes look good. We should talk more about how to solve the problem with ConnectCircuit but let's not block this.

[NTaylorMullen]

Is the problem that we have to way to show differnt UI when that happens?

Oops didn't see that you had responded to this. Yes, here's what I think would be a good alternative: #12442 (comment)