Permit configurable replacement of search tracking with client session storage

[barmintor]

fixes #2558

Implement separate client-side and server-side components for tracking search session, displaying appliedParams block in show view, and displaying result pagination from show view

Configuration

The track_session_storage configuration changes in this PR from a true/false flag to either false or a configuration object that responds to the keys storage, applied_params_component, item_pagination_component

The default value for this configuration in this PR is:

storage: "server",
applied_params_component:  Blacklight::SearchContext::ServerAppliedParamsComponent, # introduced in this PR
item_pagination_component: Blacklight::SearchContextComponent

This configuration reproduces the legacy enabled behavior; setting the configuration to false is also supported.

The new configuration available is:

storage: "client",
applied_params_component:  Blacklight::SearchContext::ClientAppliedParamsComponent, # default when client
item_pagination_component: Blacklight::SearchContext:: ClientItemPaginationComponent # default when client

Index Behavior

In the storage: "client" configuration, clicking on a search result stores the current search (query string) in sessionStorage, and submits a form that GETs the show view with a counter parameter (without POSTing to the track URL). The page links information (ie, previous/next and result set size/offset display) is added dynamically with data fetched from the current search controller in the show view. This dynamically generated form is not used if the item is being right-clicked or context-clicked (for example, when opening in a new tab).

Show Behavior

In the storage: "client" configuration, a show view that has a URL param for counter will fetch JSON data from a new controller action called page_links that returns previous/next information based on the counter and the currently stored search. If no search is available in the sessionStorage or no data is returned, the scaffolding for search context is removed.

[jcoyne]

Is it necessary to use onLoad here or can this function be called by doSearchContextBehavior? I think it's confusing to depend on both approaches.

[barmintor]

doSearchContextBehavior adds an event listener for clicks, which doesn't inspect the DOM (yet). The "page links" behavior in the show view depends on DOM content. I'm trying to refactor.

[barmintor]

ok, pushed a refactor up. I think that I have to either piggyback on Blacklight.onLoad 's event detection, or I would have to reimplement it. I at least relocated the event handler attachment and the onload addition to doSearchContextBehavior.

[hackartisan]

It's important to document the implications of this PR. Where?

[cbeer]

I think it'd be good to split the search history tracking from search context pagination. Spotlight, for example, has a pretty significant dependency on search history, but I think it'd be great to get this better client-side context in play too.

I don't think that's necessarily a blocker to merging this, but would be a nice compatibility thing for downstream users.

[barmintor]

I updated the PR description to be more explicit about the changes here.

[barmintor]

@cbeer I think it would be good to redesign saving a search as an explicit user action? Have a button on the index view if you are logged in to save the search, rather than passively logging searches.

[jcoyne]

@barmintor This has a conflict and needs to be rebased (and re-build the javascript).

[barmintor]

@jcoyne assuming we are pursuing the breaking-API PR for 8.0, I'll need to fix this PR up afterwards. I'm converting to draft while I work on #2970