Support multiple search instances on a single page (main)

[alijaber-atmire]

References

• Fixes Search components only partially support multiple instances on a single page #5738
• Related backports:
  • 9.x: Support multiple search instances on a single page (9.x) #5739
  • 10.x: Support multiple search instances on a single page (10.x) #5740

Description

Extends the per-search-instance prefixing (currently only applied to sort and pagination) to all remaining search route and query parameters, so multiple search components can coexist on a single page without interfering with each other.

Instructions for Reviewers

This builds on the existing mechanism that prefixes sort/pagination params with a unique search-instance identifier, and applies the same approach to every other search parameter.

List of changes in this PR:

• Added a searchInstanceId to SearchConfigurationService and helper methods to build/read instance-scoped parameters: getSearchInstanceParam, getCurrentSearchInstanceParam, getCurrentSearchInstanceQueryParam, getSearchInstanceFilterParam, getCurrentSearchInstanceFilterParam, and getSearchInstanceFilterParamPrefix.
• Updated getCurrentConfiguration, getCurrentScope, getCurrentQuery, and getCurrentDSOType to resolve their values from instance-prefixed route/query parameters (with a fallback to the legacy unprefixed parameter for backwards compatibility).
• Updated SearchFilterService and SearchService to read/write the f.xxx filter parameters and view using the instance prefix.
• Updated the search UI components that emit search params — search.component, search-form.component, search-results.component, search-settings.component, search-switch-configuration.component, search-navbar.component, search-page.component, configuration-search-page.component, themed(-configuration)-search.component, the facet/range filter option components, and object-collection.component — to use the instance-prefixed parameter names.
• Updated the relation-lookup-modal search/selection/external-source tabs, recent-item-list, my-dspace-configuration.service, and my-dspace.guard to use the new instance-scoped params.
• Updated specs and the search-configuration-service/pagination-service test stubs accordingly.

How to test (multiple search instances):

1. Build and run the UI (yarn start / npm start).
2. Render a page containing two independent search instances. Each instance needs its own SearchConfigurationService injection, so use two separate ConfigurationSearchPageComponent/SearchPageComponent instances — not two SearchComponent instances sharing a single SearchConfigurationService. Because searchInstanceId is stored as an instance variable on the service, two SearchComponents backed by the same service would overwrite each other's id.
3. Give each instance a unique searchInstanceId by explicitly passing it in (e.g. [searchInstanceId]="'first'" and [searchInstanceId]="'second'"), since the components default to the same id otherwise.
4. In one instance, change the query, scope, configuration, view mode, dsoType, and apply facet/range filters.
5. Verify the URL params for that instance are prefixed with its id (e.g. first.query, first.f.author, first.configuration) and that the second instance is unaffected, and vice versa.
6. Confirm a single-search page (default instance id) still behaves as before.

How to test (backwards compatibility of legacy URLs):

1. With a single search page, open a URL that uses the old unprefixed parameters (e.g. /search?query=cats&f.author=Smith,equals&view=list), as produced by older versions / external links / bookmarks.
2. Verify that on load the legacy params are migrated to their instance-prefixed equivalents (e.g. the URL is rewritten to spc.query=cats&spc.f.author=Smith,equals&spc.view=list) and the search results, active filters, and view mode reflect those values.
3. Verify that when both a legacy and an already-prefixed param are present, the prefixed one takes precedence and the legacy one is dropped without overriding it.
4. Confirm that subsequent search interactions (new query, adding/removing a filter, paging) operate only on the prefixed params and don't reintroduce the legacy ones.

Checklist

• My PR is created against the main branch of code — N/A: this is a version-specific PR targeting dspace-10_x (the bug is being fixed on the 7.6/9.x/10.x lines).
• 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.