Further optimize initial page load by leveraging preboot

[artlowel]

Describe the bug In https://github.com/DSpace/dspace-angular/pull/1627 we've used a number of strategies to mitigate the problem that pages appear to load twice: they come back from the server fully rendered, but then are constructed again when the client JS code starts up

That works well for the home page, because we can predict what will be needed there and load it immediately, rather than lazily load it afterwards. However we can't do that everywhere without increasing the initial JS download further (and it is already rather large). So as a consequence on most pages other than the homepage you'll still see a flicker on the first page load, though https://github.com/DSpace/dspace-angular/pull/1627 made it much quicker and less noticeable

We can likely further improve upon this by using preboot, a library to smooth the transition from server-side rendered pages to client-side rendering, by doing things like replaying server side events on the client, buffering, ensuring the focus is retained when re-rendering, etc. (not to be confused with the preboot option in our current config, which basically just enables SSR)

We've done a few initial tests, and the results look promising:

Without preboot

https://user-images.githubusercontent.com/1567693/179940500-9d3eff79-e1b3-4f92-a522-194af6aab75f.mov

With preboot

https://user-images.githubusercontent.com/1567693/179940540-64db2065-f326-46ad-a454-eb5ff5c8373c.mov

However simply adding and enabling it as we've done here creates a few other problems, such as unexpected page reloads when using the header search field for example. It also looks like we'll need at least some of the workarounds for https://github.com/angular/preboot/issues/75

We'd like to see if we can work out the kinks and create a PR. We'll take a max of 20h

Related work https://github.com/DSpace/dspace-angular/pull/1627

[tdonohue]

@artlowel : This seems worth looking into. I would caution though that I'd be good to ensure it doesn't take up too much time for 7.4... I feel the fixes in 7.3 are significant (over 7.2 and prior). This seems like another good fix, but I don't want it to take away significantly from fixing other high priority issues on our board.

So, I'm fine with spending 20hrs on this. But, if it becomes more than that, I'd recommend we consider pushing this to 7.5. In any case, for now I'll assign to you with the 20hr max on it, and move it to 7.4 board