Add NotFoundPage to Router

[ilonatommy]

Description

• Adds NotFoundPage parameter that can be used to customize the view of page rendered on NotFoundEvent.
• Fixes the configuration without global router: then no subscription to _notFound was done, so we use redirection to a hardcoded not-found page.
• Fixes the SSR streaming configuration. In streaming scenario we typically want to set 404 after the response already started (e.g. after request to a db). Throwing an exception in this case does not look good. Instead, we ignore the 404 there and redirect to NotFound page.
• If SSR streaming did not start or is not enabled, we can reexecute the request and set the result url to a chosen path, using app.UseStatusCodePagesWithReExecute("/reexecution-path", createScopeForErrors: true);

Fixes #58815

[javiercn]

Looks great!

I think we will also want to update the project templates to use this feature.

In addition to it, I think there's another scenario we want to enable here which is to make sure that it works with UseStatusCodeWithReexecute

• UseStatusCodeWithReexecute allows the app to render a page after a 404 has been set somewhere. We want that to also be possible with a Component page

I did something similar for handling errors a couple releases back. This is the PR with the change for reference #50550

• I suspect we will need to do something similar here.

/cc: @danroth27

[javiercn]

I think the interface we are looking for is IStatusCodeReExecuteFeature not IStatusCodePagesFeature. The latter is added all the time to the middleware, while the first one is only added by the handler when it's dealing with the re-execution code path, which I think is what we want (and is the equivalent of isErrorHandler)

[ilonatommy]

This complicates the logic a bit. We need a way to avoid writing the response (so return from RenderComponentCore method before flushing) if we expect re-execution. By "expect" re-executon I mean: status code page was set, we used to have a 200 but now we have 404. At the place where we would like to detect it, IStatusCodeReExecuteFeature is unset and we have no way of preventing starting the response.

We could set IStatusCodeReExecuteFeature for in the handler subscribed to OnNotFound event: in SetNotFoundResponseAsync. This forces us to add <Reference Include="Microsoft.AspNetCore.Diagnostics" /> to Microsoft.AspNetCore.Components.Endpoints.csproj. Is this acceptable?

Otherwise, we will return too early to handle re-execution, again this condition:

aspnetcore/src/Middleware/Diagnostics/src/StatusCodePage/StatusCodePagesMiddleware.cs

Line 67 in 55a1ae7

if (context.Response.HasStarted

[ilonatommy]

Relying on IStatusCodeReExecuteFeature fails - the result is that we always flush the response and we never have a chance to re-execute.
The problem here is that we would like to detect the page that is going to re-execute, to prevent writing to its contents, not a page that already was re-executed.

[ilonatommy]

In error handler we don't have such a problem (we don't have to detect to return early) because the thrown exception does it for us. We never execute any code after RenderEndpointComponent in EH case. For 404 we have to return early based on a condition.
The most reasonable is probably IStatusCodePagesFeature->set & IStatusCodeReExecuteFeature->unset & responseCode->404.

[javiercn]

I don't fully follow, but I don't think we need to block on this

[ilonatommy]

The failing test is known but we don't have conditional build analysis in this repository.

[javiercn]

nit: I don't think this is blocking, but we shouldn't throw for this case, noop-ing is fine.

[javiercn]

Looks great, I think there are some things we need to tweak, but nothing critical we need to block on for preview4.