Search Results should be loaded using fewer REST requests

[tdonohue]

Describe the bug

In 7.x and 8.x, when a user searches the system, this makes many calls to the REST API to load all the required information to display on the search page. Currently, it first loads the results, then each facet (one by one), then any thumbnails and "accessStatus" (if enabled). We should be able to decrease the number of calls made on this page.

Here's what it looks like on the sandbox.dspace.org in Chrome DevTools when running a search on "test":

# Run Actual search
GET /server/api/discover/search/objects?sort=score,DESC&page=0&size=10&query=test&embed=thumbnail&embed=item%2Fthumbnail&embed=accessStatus

# Load each facet one by one
GET /server/api/discover/facets/author?page=0&size=5&query=test
GET /server/api/discover/facets/subject?page=0&size=5&query=test
GET /server/api/discover/facets/dateIssued?page=0&size=5&query=test
GET /server/api/discover/facets/has_content_in_original_bundle?page=0&size=5&query=test
GET /server/api/discover/facets/entityType?page=0&size=5&query=test

# Load thumbnails for each returned item
GET /server/api/core/items/[uuid]/thumbnail
...

# Load accessStatus for each returned item
GET /server/api/core/items/[uuid]/accessStatus
...

We should be able to minimize the number of calls here by using Projections (embed parameter). It may still be necessary to load thumbnails individually though.

To Reproduce

Steps to reproduce the behavior:

1. Visit demo.dspace.org or sandbox.dspace.org
2. Open Chrome DevTools
3. Run a search. Verify that you see a large number of REST requests to build the search results page.

Expected behavior

Ideally, better usage of projections should allow us to load all this information in fewer REST requests. If additional endpoints need to be added to the REST API to support this behavior, then we should add them.

[paulo-graca]

Related issue: DSpace/DSpace#9316

[ybnd]

We've investigated the repeated /thumbnail and /accessStatus requests before and concluded that they were due to mis-caching of empty/nonexistent embeds. Could contribute a fix.

[tdonohue]

@ybnd : If you have a fix in place, that'd be wonderful. I think this is related to DSpace/DSpace#9316 which I see is also assigned to Atmire. So, both might be fixed in one PR.

Assigning to you & moving to "in progress"