Interactivity Router: Support Handling navigate() Failure States

[ObliviousHarmony]

What problem does this address?

When the page that you are requesting returns a non-2xx response the navigate() function in @wordpress/interactivity-router does a full page reload. This prevents blocks from deciding how to handle the failure state themselves, such as navigating to a different page.

What is your proposed solution?

A new option should be added to navigate() or prefetch() that bubbles the failure state up so that the consuming block can decide how to handle it. With that aid, I think there's some discussion to be had first around how much we should let escape the abstraction. Here are two ideas that come to mind for me:

1. The most naive approach would just be an option for navigate() that prevents the full page reload. This maintains the abstraction, however, it also doesn't really leave the caller with any actionable information about the failure itself. All they know is that a non-2xx status was received and so they just have to assume why it failed.
2. A deeper solution would be for fetchPage() to return information about non-2xx responses when the option is provided. This could be bubbled up in navigate() and prefetch() and returned to the caller. This provides the best error handling but could potentially be seen as leaking too much. Since it's opt-in I don't know that it would be a problem.

Since this would require the caller to pass an option I don't think it would be problematic to return more detailed information about the error. One consideration though is that it might be a good idea to create our own error object rather than returning the HTTP response content.

[ObliviousHarmony]

For posterity, this suggestion comes from problems with pagination in the Product Collection block in WooCommerce. Since page reloads happen whenever the filters change, this can leave you on a page that ceases to exist under the new filtering conditions. When this happens a 404 error is returned and the page does a full refresh to the 404 page. We can just reset the page before each refresh but I think it highlights a potential deficit in the router.