chore: New demo server featuring SSR

[TrevorBurnham]

Description

I've been trying to build a Cloudscape app that uses SSR. In doing so, I've found a number of inconsistencies between the visual state when components are rendered server-side vs. when they're rendered client-side. However, these bugs are difficult to replicate and fix, which has made it difficult to contribute patches (see e.g. #3856, #4065, and #4123).

This PR replaces the existing demo server (npm run start:dev) with a new one that features SSR. This should make it much easier to spot SSR bugs, and to confirm fixes.

The new server should be backward-compatible with the old one, though a couple of (hopefully minor) issues are worth pointing out:

Time to hydration

It takes ~2s for client-side rendering to kick in, mainly because of the large number of JS and CSS files served on the page. That means that the page is non-interactive during that time. It also means that any screenshot taken before that time would reflect an SSR bug, not what a component looks like when rendered client-side.

For Cloudscape's visual diff tests, we'll need to ensure that those visual diff tests wait for hydration before taking a screenshot. If they already wait for all resources on the page to load, that should be sufficient.

URL redirection

The old demo server used hash-based routing, e.g.

http://localhost:8080/#/app-layout-toolbar/with-content-layout

Hashes can't be read by the server, so supporting SSR requires path-based routing, e.g.

http://localhost:8080/app-layout-toolbar/with-content-layout

There's a client-side redirect for hashes, so hash-based routes will still take you to the correct page, but the initial SSR-rendered page will be the home page.

How has this been tested?

I've run the server and poked around quite a bit, but I'd welcome more suggestions for testing.

Review checklist

The following items are to be evaluated by the author(s) and the reviewer(s).

Correctness

• Changes include appropriate documentation updates.
• Changes are backward-compatible if not indicated, see CONTRIBUTING.md.
• Changes do not include unsupported browser features, see CONTRIBUTING.md.
• Changes were manually tested for accessibility, see accessibility guidelines.

Security

• If the code handles URLs: all URLs are validated through the checkSafeUrl function.

Testing

• Changes are covered with new/existing unit tests?
• Changes are covered with new/existing integration tests?

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.