Refactor menu resolvers 9.0

[YanaDePauw]

References

Fixes #3262

Description

This PR refactors the menu sections that were previously provided in the various menu resolvers. Instead of the previous system where all the sections are added in the same resolver and need to be managed manually through indexes, the new system will split up all the sections over multiple "Providers" which will then be added to the list of providers per menu defined in the app.menus.ts file.

export const MENUS = buildMenuStructure({  
  [MenuID.PUBLIC]: [  
    CommunityListMenuProvider,  
    BrowseMenuProvider,  
    StatisticsMenuProvider,  
  ],  
  [MenuID.ADMIN]: [  
    NewMenuProvider,  
    EditMenuProvider,  
    ... 
    SystemWideAlertMenuProvider,  
  ],  
  [MenuID.DSO_EDIT]: [  
    DsoOptionMenuProvider.withSubs([  
      SubscribeMenuProvider.onRoute(  
        MenuRoute.SIMPLE_COMMUNITY_PAGE,  
        MenuRoute.SIMPLE_COLLECTION_PAGE,  
      ),  
      ...
      ClaimMenuProvider.onRoute(  
        MenuRoute.SIMPLE_ITEM_PAGE,  
        MenuRoute.FULL_ITEM_PAGE,  
      ),  
    ]),  
  ],  
});

This approach makes it way more intuitive to see what kind of sections there are and to add new sections in between already existing ones.

This new version fully removes the old way of adding route based data (e.g. statistics) and replaces it with a new way where you can easily add routes to specified providers and/or retrieve route data in the provider to be used for its sections. It also adds support to separately define a parent sections with various child sections. The latter will be mostly useful for creating sections on the DSO pages where you can now separately define the parent section through a provider and then add child providers for the various different sections.

For example, in the current implementation all the buttons on the DSO pages have been added to a single parent parent section resulting in a single button on the DSO pages with the relevant sections in the dropdown. In case sections need to be moved, the provider can simply be moved to a different location such as before the provider responsible for providing the button (DsoOptionMenuProvider).

Finally, since the menus have been moved from the resolvers to the InitService, the menus will not delay the page from loading when the menu sections need some time. The menus will simply appear when they are fully loaded. To prevent "blinking" when changing pages, the sections that need to be added/removed are all done at the same time.

Instructions for Reviewers

The current menus and its sections should be the same except for two exceptions. Therefore, verifying that the behaviour has remained the same for those sections should be sufficient to verify that the refactor was successful.

The two exceptions are the following:

Exception 1: Statistics section
The behaviour of the statistics menu has been changed to show a menu on all pages instead of only the home page and the DSO pages.

When a DSO is present somewhere in the route, it will redirect to that DSO's statistics page, otherwise it will redirect to the general statistics page.

For example, when you are on the edit page of an item, the statistics link will still navigate to that item's statistics. When on the "Scripts and processes" page, the statistics link will navigate to the general repository statistics.

Exception 2: DSO options wrapper section
The various buttons on the community, collection and item pages have all been added to a single dropdown menu instead of having separate buttons per section. This results into a cleaner look compared to having a growing list of different buttons being added on those pages.

Note: In case people would want to restore the old view, this can be easily done by removing the DsoOptionMenuProvider.withSubs() provider and adding all the menus that were in the .withSubs list directly to the [MenuID.DSO_EDIT] list.

Documentation

Due to the majority of the changes, some documentation will be provided separately.

Checklist

This checklist provides a reminder of what we are going to look for when reviewing your PR. You do not need to complete this checklist prior creating your PR (draft PRs are always welcome).
However, reviewers may request that you complete any actions in this list if you have not done so. If you are unsure about an item in the checklist, don't hesitate to ask. We're here to help!

• My PR is created against the main branch of code (unless it is a backport or is fixing an issue specific to an older branch).
• My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
• My PR passes ESLint validation using npm run lint
• My PR doesn't introduce circular dependencies (verified via npm run check-circ-deps)
• My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
• My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
• My PR aligns with Accessibility guidelines if it makes changes to the user interface.
• My PR uses i18n (internationalization) keys instead of hardcoded English text, to allow for translations.
• My PR includes details on how to test it. I've provided clear instructions to reviewers on how to successfully test this fix or feature.
• If my PR includes new libraries/dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
• If my PR includes new features or configurations, I've provided basic technical documentation in the PR itself.
• If my PR fixes an issue ticket, I've linked them together.

[YanaDePauw]

Note: e2e test issues

There are still some e2e tests failing due to these requiring certain ids for certain menus while most of the menus do not have human readable ids anymore. These are being fixed.