Progressively load releases on the Releases page

What does this MR do?

Updates the Releases page to progressively load releases, in order to improve this page's perceived performance and its LCP metric.

Previously, the page would make a request for all ten releases on the page, and show a loading indicator until the request completed.

Now, the page sends two requests:

• 1 request for the release #1
• 1 request for releases #1-10

The request for the single releases returns much faster, which allows the page to show a single result much more quickly. When the remaining releases finish loading, they are inserted into the page after the first.

Other user-facing changes

This MR makes one other user-facing change. Previously, if the project contained between 1 and 10 releases, the pagination controls at the bottom of the page would be hidden. Now, the pagination buttons are shown, but both buttons are disabled.

Why?

I just like this better 🤷 It felt weird to fully hide the controls as we were doing before. It also simplified the implementation and tests.

Screenshots/GIFs

Before

Average LCP¹: 4905 ms

After

Average LCP¹: 3469 ms ≈ 30% improvement in perceived performance

¹How I measured LCP: In my local GDK, I created 10 releases with the content of the first 10 GitLab releases. I loaded the Releases page in Google Chrome 5 times and averaged the reported LCP times. This is not very scientific - and my local GDK performs very differently than GitLab.com - but hopefully this gives a general idea of the performance impact. This will need to be tested on GitLab.com to understand its real impact.

Next steps

The query that makes the request for the single item (or maybe even both queries?) can be converted to be a startup query, which should allow these requests to be made even earlier in the page lifecycle.