Part of #61738

In scope of #81633, #81489 we implemented initial ?searchSessionId query parameter support in discover and dashboard.

Initial implementation is simple and in terms of when we remove this query parameter this works in following way:

Current behavior:

1. Land into dashboard with ?searchSessionId in the URL
2. Initial search is executed with restored session. ?searchSessionId
3. On state change or explicit refresh new session starts. ?searchSessionId is removed from the URL using replace
4. Because replace was used on a browser "Back Button" we don't restore the ?searchSessionId and don't restore background search results.

Expected behavior:

1. Land into dashboard with ?searchSessionId in the URL
2. Initial search is executed with restored session. ?searchSessionId
3. On state change or explicit refresh new session starts. ?searchSessionId is removed from the URL together with other URL changes.
4. On a browser "Back Button" we restore the ?searchSessionId and restore background search results.

Why we didn't implement expected behavior initially? Doesn't sound like this should be a problem

Because of complicated state management and sync state with URL from multiple places we have to make sure the URL update which removes ?searchSessionId happens in a single transaction with other URL state updates (e.g. filter removal) to avoid multiple history entries.

This would either require an improvement to existing state syncing utils or even implementing platform api for batching history updates: #58752 (comment)

cc @lizozom @lukasolson