10804 componentizing core search

[whatisgalen]

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Description of Change

Fundamentally, here's what this PR tries to accomplish:

• Greater Extensibility: for search customizations to be more useful to the community, they must be easy-ish to "plug in". Overriding the Search view in a project doesn't really meet that criteria. Creating a component that lives in your project makes a lot more sense. For Arches to be able to switch out its core search logic, however, that core search logic needs to be removed and moved into a component itself
• Outsource technical debt from the SearchView onto search_components: By stripping down one of the core methods (search_results) to just: initialize a SearchEngine, create a response object, and call 3 standard methods from each ordered set of search filters, there's less of a reason to tinker with the search view and development can be channeled into the search_components.

Specifically, here's an overview of the changes:

• a special component called a SearchLogicComponent governs both what search components are available to the frontend (and what the frontend logic is) as well as what search components are required on the backend and how to handle the search request
• search.htm is just a placeholder for whatever template the search-logic component has and search.js doesn't do much beyond set up the necessities and send a request to get a SearchView. SearchLogic can be set as default when none is provided, or it can be provided as a named parameter in the url: search?...&search-logic=custom-search-logic
• a migration inserts the arches default core logic called standard-search-logic along with changes to specific components and adding a config column to all.
• search components extending BaseFilter class methods (append_dsl, etc.) now take the entire response_object and bundled kwargs as opposed to specifically a results object or include_provisional kwargs, respectively.

Issues Solved

#10804

Checklist

• Unit tests pass locally with my changes
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)

Ticket Background

• Sponsored by: @scholiumtech
• Found by: @whatisgalen
• Tested by: @apeters
• Designed by: @whatisgalen

Further comments

[whatisgalen]

The latest commits address all requested changes except for finalizing specific values for search_component.type

[apeters]

Almost there!

[apeters]

shouldn't this be this.getFilterByType('map-filter-type', false)

[whatisgalen]

if you check out line 61: if (tab === "map-filter") { the value for tab comes from that search-filter's component name, so even if another filter like galen-map-filter was the right type ("map-filter-type"), the tab wouldn't be called "map-filter". If that check weren't there, I would agree that it should just be getFilterByType.

In short: we need to ensure that the filter we're assigning to this.mapFilter is the same one we're calling via if (tab === "map-filter")

[apeters]

should this have been removed?

[whatisgalen]

yes, see @jacobtylerwalls comment

[apeters]

phew! that took a while but I think it was worth it!