Add search summary panel and full filter support

[jazairi]

Why these changes are being introduced:

It would be helpful if users could see what filters they've applied to a search directly below the search bar, which would also provide another path to remove filters.

Relevant ticket(s):

https://mitlibraries.atlassian.net/browse/GDT-142

How this addresses that need:

This provides the requested panel. We had been calling this a "filter removal" panel, but I ended up naming the partial search_summary to avoid any confusion with the filter sidebar. However, the currently displayed data has the filter-removal class, because it's likely we will want to show advanced search terms here, too (possibly just for screen readers).

While working on this, it occurred to me that the existing TIMDEX UI filter implementation is incomplete. It pulls in the aggregation names and uses those as the internal filter names. This works fine for the existing contentType and source filters, but it will cause a name collision for filters that also exist as regular search inputs (e.g. contributors vs. contributorsFilter). Since we will be adding more aggregations and filters soon, it makes sense to fix this problem now.

Side effects of these changes:

• The "You searched for" list has been removed, as this feature replaces it. As mentioned above, we will likely want to provide that information in some manner in the search summary, but that will require some discussion with Darcy, who is out-of-office at the moment.
• Filter keys are now cast as symbols throughout the application. Previously, they would be strings in some places and symbols in others. I found that confusing, but if this change is even more confusing, I'm happy to revert it.
• A few tests have been skipped due to the removal of the "You searched for list". I chose not to delete them in case we reintroduce that feature in the near future.
• Most of the cassettes have been regenerated, due to changes to the TimdexSearch model.

Developer

• All new ENV is documented in README
• All new ENV has been added to Heroku Pipeline, Staging and Prod
• ANDI or Wave has been run in accordance to
  our guide and
  all issues introduced by these changes have been resolved or opened as new
  issues (link to those issues in the Pull Request details above)
• Stakeholder approval has been confirmed (or is not needed)

Code Reviewer

• The commit message is clear and follows our guidelines
  (not just this pull request message)
• There are appropriate tests covering any new functionality
• The documentation has been updated or is unnecessary
• The changes have been verified
• New dependencies are appropriate or there were no changes

Requires database migrations?

NO

Includes new or updated dependencies?

NO

[coveralls]

Pull Request Test Coverage Report for Build 7978579909

Details

• 0 of 13 (100.0%) changed or added relevant lines in 4 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.008%) to 99.452%

---

Totals
Change from base Build 7892634244:	0.008%
Covered Lines:	363
Relevant Lines:	365

---

💛 - Coveralls

[JPrevost]

I'm not really asking for changes so much as asking for confirmation on next steps prior to approval as this works great, but the wording is really difficult for me to accept without knowing what we're going to do about it :)

[JPrevost]

Does this feel like a workaround to a deficiency in our API? Or is this something only our UI is likely to encounter?

It feels like we should be returning our aggregations using the same terminology as we use to apply them. So instead of returning source we should return that aggregation as sourceFilter so it is clearer how to use the data. Thoughts?

[jazairi]

Possibly. I hate this code, and manipulating the response this much in the UI certainly feels like a workaround, but I don't know if I'm convinced we should change our aggregation names. Since they're not filter/filters aggregations, naming them as such might be confusing to other consumers. Less confusing than having different names for the corresponding aggs, though? I'm not sure.

[JPrevost]

I know you brought this to the team last week, but after seeing in action, I'm fairly hesitant to remove this feature as it reads very weird the way it is implemented as it feels like it sits halfway between "these are all the things you searched for" and "these are the filters that are applied but please look at the form above for the rest of the values you searched for". i.e. the words say one thing but the implementation is the other... which is awkward.

My preference would be to label it in the way it is currently functioning (Applied filters: ...) as that feels like the easiest solution for now even if it doesn't match the requested wording. The alternative would be to add all of the various searchable bits to this new panel which honestly feels like a better longterm direction.

If there is a ticket to resolve this distinction after talking with UX when they are back from vacation, I could probably get over this :)

[jazairi]

I'd strongly prefer changing the label to Applied filters. In my opinion, the "You searched for" list is redundant with the expanded form. (And, honestly, I'm not sure what these tests are confirming, except that these fields show up in the enhanced query.)

[jazairi]

Also, sprint planning reminded me that I created a ticket to figure out what we want to do with advanced search terms: https://mitlibraries.atlassian.net/browse/GDT-196