Today, when we get PRERENDERING_FAILED, we do not try another request.  However, PRERENDERING_FAILED is a combination of causes, some are continuable, some are not.  We should break this apart into continuable and non-continuable cases, and allow the next request to proceed on a continuable case.


From the mail thread:
----------------------------------
The PRERENDERING_FAILED_NO_RETRY code is defined just for that request - experienced a hard-ish failure so we should not retry that specific request. 
But we can/should try another one.

The PRERENDERING_CANCELED code is meant to indicate that maybe now is not a good time to try any more prerendering so should not try another request yet.
This happens for the UNSUPPORTED_SCHEME status and if the prerenderer cancels the operation (which can be for resource pressure).

So, I think the open issue is with the PRERENDERING_FAILED code. Currently we will not try another request but maybe we should. However, there is a potential
concern with trying another request if the failed request is the only available request as it could loop through all the attempts while some transient condition was causing
the failure. This was a more realistic concern when we could get the RECENTLY_VISITED code as it would fail very fast. There are some codes that I wonder if
we should still stop processing - MEMORY_LIMIT_EXCEEDED and RENDERED_CRASHED. There is another one I am curious about how it happens and so how
we should handle continuing: NEW_NAVIGATION_ENTRY.

So I wonder if we should add a new enum code for MEMORY_LIMIT_EXCEEDED and RENDERER_CRASHED at least where we do not continue processing but
we do for other FAILED cases. PRERENDERING_FAILED_STOP_PROCESSING?