Reconcile NavigationManager behavior to no longer use NavigationException

[javiercn]

The behavior NavigationManager exhibits is different in SSR rendering than it is on other interactive modes. In particular, SSR relies on throwing an exception that gets captured by the framework to convert the error into a redirect.

This behavior leads to a poor user experience where users debugging their apps typically see the debugger break when this exception is thrown and incorrectly believe that there is an error/bug on the framework.

In addition to this, code that exists after a call to NavigateTo will continue to execute on interactive render modes but will abruptly stop in SSR scenarios.

The solution for this involves a breaking change, but the number of issues that the current behavior produces justifies such change. We should stop throwing an exception during SSR and instead signal the underlying renderer that a redirection has been requested. We should continue to execute the current ongoing synchronous render batch until completion and, once it finishes, we should dispose the existing renderer and trigger the redirect. This will align the behavior with what happens in other platforms, but we should also have a suite of tests that capture these behaviors across render modes to ensure a consistent experience.

For backcompat reasons we will include an AppContext switch that will continue to throw the exception in case someone needs it.

[javiercn]

Related issue #53996

[michaelongithub]

Hi
@javiercn:
contrary to .net 8 using the NavigationManager.NavigateTo in an OnInitilized/Async (Blazor Server) is creating a runtime Error as it did up to .net 6 and now again in .net 9. Would you consider this to be treated with the same idea you proposed or do you think this is another type of problem ? Used this in .net 8 a lot without running into problems. Or just revert back to moving it to OnAfterRender and mange what is displayed before ? Which is cumbersome. Would be interested in your thoughts.