Switch the Page List block to client-side rendering

[priethor]

What problem does this address?

The Navigation block is prone to a lot of direct manipulation to customize its look and feel. Because the Page List block is server-side rendered, its manipulation can offer a poor user experience: user interactions can take a few seconds to apply on certain conditions, and this issue only becomes bigger as more design tools are added.

Grabacion.de.pantalla.2021-10-14.a.las.13.48.35.mov

What is your proposed solution?

Switching the Page List block to render on the client side would avoid the slow re-rendering it currently suffers.

[tellthemachines]

We'll want to test this with a large amount (hundreds) of pages, because the reason for using server side rendering initially was really bad performance with client side render.

I think @gwwar had some ideas about how we could improve performance on the client (there may even have been an issue at some point? but I can't find it 😅 ).

[gwwar]

Re: performance I think that one was mostly about us limiting requests to 100 per page, and trying to fetch all resources. (many many requests). We could pre-load the endpoint, but I think it might be reasonable to think through limits on what we display for the PageList.

In the navigation block we intend it to be a quick start for a nav menu (which we assume to be somewhat limited), and outside of that context it could function more as a Table of Contents or directory (which we might be able to add paging to).

[ockham]

Potential fix in #31670.