Update DSO creation and edition selectors in admin menu to use more specific authorization endpoints

[toniprieto]

References

• Requires Refactor authorization-based Solr queries and add new findAddAuthorized/findEditAuthorized endpoints DSpace#11646

Description

This modification updates the community, collection, and item selectors used in the DSO admin menu for creation and edition. This ensures that the listed objects are correctly filtered by the user's permissions, which specifically addresses the item selector for edition that currently does not filter items based on the user's edit authorization. Additionally, some selectors now utilize the more specific endpoints, findAddAuthorized and findEditAuthorized (introduced in the backend PR), instead of the previously used findAdminAuthorized endpoint.

Instructions for Reviewers

List of changes in this PR:

• New methods have been added to the item, community, and collection data services to utilize the specific new authorization endpoints (findAddAuthorized and findEditAuthorized).
• Modified the authorized-DSO-selector components to include a new parameter that specifies the required action the current user must have on the returned objects (e.g., ADD or WRITE or ADMIN).
• Adapted the DSO selection pop-ups (used in creation and edition menus) to call the specific selector with the required authorization action.

Note that because the UI currently requires administrator permissions to edit communities and collections, these two selectors use the findAdminAuthorized method.

The key test is to verify that the Item selector for edition now only shows items that the logged-in user is authorized to edit. For detailed instructions on how to test, please refer to the backend PR: DSpace/DSpace#11646

• 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.