Reduce request chaining and associated overhead

[ybnd]

As described in #3110 (comment) and #3110 (comment), many DSpace REST requests show multiple other requests as "initiators".

We're currently investigating the following avenues:

• Reducing the amount of chained requests
  • The example in the comments above mentions search filters, which depend on a chain of at least the following requests:
    • /server/api → HAL endpoint map
    • /server/api/discover → HAL endpoint map for discovery
    • /server/api/discover/search → HAL endpoint map / default search configuration
    • /server/api/discover/objects and/or /server/api/discover/facets → determine which facets are visible
    • /server/api/discover/facets/<:id> → finally retrieve the actual filter
  • These can be direct (within the same RxJS pipe) or indirect (components rendering after a response is received and sending their own requests)
• Assessing our total NgRx/RxJS overhead
  • We may want to try and tackle request chains by embedding more or pre-caching, but we'd still go through a long stack of NgRx selectors and RxJS operators
  • Intuitively we think that this shouldn't have too much impact, but it's not immediately clear how to measure this