feat: CXSPA-6890 Create toggle and optimization options for propagating errors to the server

[pawelfras]

PR contains toggle for propagating async errors captured during SSR to the server. Apart from that, it contains additional optimization options to configure the rendering cache - required as we're going to handle errors, which we discourage caching.

QA steps for propagateErrorsToServer toggle:

1. Tests in storefront app:

• call HTTP error that may be caught during server-side rendering e.g use HTTP proxy OR
• modify pages property in default-cms-config.ts to generate 'CmsPageNotFound` error.
• run npm run dev:ssr
• open the application in the browser
• verify whether the app fell back to CSR and index.html returned with status 404
• stop the app
• go to spartacus-features.module.ts and inside provideFeatureTogglesFactory set propagateErrorsToServer to false
• run app and verify whether the rendered with status 200 (as it used to be before changes around ssr error handling)

2. Tests in customer's app:

• build and deploy Spartacus packages locally:
  npx ts-node ./tools/schematics/testing.ts in the SPA root folder
• generate fresh ng17 application:
  npx @angular/cli@17 new my-app --standalone=false --ssr=false --style=scss --routing=false
• go to the project's directory and install Spartacus with SSR from local packages:
  npx @angular/cli@17 add @spartacus/schematics@latest --ssr
• use HTTP proxy or modify config for CMS endpoints to cause an error when rendering:

provideConfig(<OccConfig>{
      backend: {
        occ: {
          endpoints: {
            pages: 'cms/pages2', // FOR STATUS 404
          },
        },
      },
    }),

• provide provideFeatureToggles({propagateErrorsToServer: true}) in app.module.ts`
• in server.ts inside app function use handlers provided by Spartacus:

  const indexHtmlContent = readFileSync(indexHtml, 'utf-8');

  /** */

  server.use(defaultServerErrorResponseHandlers(indexHtmlContent));

• run npm run build and npm run serve:ssr:my-app to verify whether the app fell back to CSR and index.html returned with status 404
• close the app and remove provided toggle
• run npm run build and npm run serve:ssr:my-app and verify whether the rendered with status 200 (as it used to be before changes around ssr error handling)

QA steps for new optimization options avoidCachingErrors and cacheStrategyResolver:

• in server.ts, pass cache: true to the ssrOptions
• modify components property in default-cms-config.ts to generate async error in SSR.
• run npm run dev:ssr and run app in the browser
• verify server logs whether request has been resolved with error and in the browser if the index.html returned with status 500:

{
  "message": "Request is resolved with the SSR rendering error (/electronics-spa/en/USD/)",
 / ... /
}

• reload page and check server logs to verify if page has been taken from cache:

{
  "message": "Render from cache (/electronics-spa/en/USD/)",
  / ... /
}

• in server.ts, add avoidCachingErrors: true to the ssrOptions
• refresh the page a few times and ensure that log Render from cache (/electronics-spa/en/USD/) and rendering was triggered each time the page was reloaded
• in server.ts, add any custom cacheStrategyResolver to ssrOptions, e.g:

cacheStrategyResolver: (options, entry) => {
    console.log('MY CUSTOM CACHE STRATEGY RESOLVER');
    return !(options.avoidCachingErrors === true && Boolean(entry.error));
 }

• run app and verify if code from the custom cacheStrategyResolver was executed (If the above example was used, check server logs)

[Platonn]

cacheStrategyResolver: (config, entry) => boolean

Maybe it's only me that see this name as very ambigious. On the first sight I don't know what is a "cacheStrategy", that it wants to resolve.

What about alternatives? Examples:

shouldCachePage: (config, entry) => boolean

cacheCondition: (config, entry) => boolean

[pawelfras]

I don't mind changing this property name. What do you think about:

shouldCacheResponse: (config, entry) => boolean

shouldCacheRendering: (config, entry) => boolean

shouldCacheRenderingResult: (config, entry) => boolean

[Platonn]

shouldCacheRenderingResult is most clear to me.

+to be future proof (for adding new properties/arguments), I'd wrap args in just a single object ({ config, entry }) => ...