feat: Use new search endpoint in FE and add search filter operation selection

[kristenarmes]

Summary of Changes

This change has three major sections that are all included together for compatibility:

1. Work done by @allisonsuarez to have the frontend service point to the new search endpoint.
2. Search input filters now accept comma separated values rather than only a single value.
3. When a comma to separate multiple filter terms is typed in any input filter box, a AND/OR toggle will appear, allowing the user to specify whether they are filtering by all of the entered filter terms in the same results, or just looking for at least one of the terms in the results.

Some design decisions to note:

1. There is a new optional frontend config in the BaseFilterCategory called allowableOperation. If it is not set, the default behavior will allow both AND and OR operations for filtering. If it is set to FilterOperationType.OR, only the OR filter operation will be enabled for that category, which can be used when each search result would only ever include one of the filter terms in the category - e.g. a given table would only have one source database. If it is set to FilterOperationType.AND, only the AND filter operation will be enabled for that category.
2. A special type called FilterOptions was used to keep track of which checkbox filters were checked or unchecked where a true value meant it should be checked and a false value unchecked. Since now the input filters accept multiple values, this type was removed and the checkboxes are handled the same way as the input filters, where the name of the checkbox being included in the filter means it should be checked and any not included are unchecked.
3. Since there is now only one search API call per search rather than one per resource, when a search action for a specific resource is taken, only that resource has its state updated from the response to avoid clearing out the previous search for the other resources.
4. Previously, clearing filters would trigger an empty search in order to clear out the results. With the new API, this was causing an error because it did not expect to get empty searches, so instead of doing an unnecessary API call when clearing filters it will just clear the results state instead.

Tests

Various changes were made to JS tests to account for changes to the way the frontend data is handled with filtering, such as checkboxes using a list of values rather than a special type to make it more consistent with the input filters. New tests were added for the AND/OR toggle behavior.

Documentation

frontend/docs/application_config.md was updated to account for the renamed filter category types, along with fixing outdated links.

CheckList

Make sure you have checked all steps below to ensure a timely review.

• PR title addresses the issue accurately and concisely. Example: "Updates the version of Flask to v1.0.2"
  • In case you are adding a dependency, check if the license complies with the ASF 3rd Party License Policy.
• PR includes a summary of changes.
• PR adds unit tests, updates existing unit tests, OR documents why no test additions or modifications are needed.
• In case of new functionality, my PR adds documentation that describes how to use it.
  • All the public functions and the classes in the PR contain docstrings that explain what it does

[Golodhros]

Looking great!

Only some minor comments

[Golodhros]

LGTM

Thanks for going the extra mile!

[kristenarmes]

Another way of doing this on an immutable way would be:

      // Remove the categoryId from the filters if the new value is empty
      const {[categoryId]: remove, ...updatedResourceFilters} = filterState[resourceType];

      newFilters = {
         ...filterState,
         [resourceType]: updatedResourceFilters,
      };

This would avoid the 'delete', that is a mutating operation (although made on a copy of the object)

@Golodhros I did it this way at first actually, but found I was getting a linting error because the remove is an unused variable. I didn't know if it was preferable to do it like this but then disable the no-unused-vars check for this spot? I figured the delete on the copy of the object was a middle ground to avoid linting issues but not directly mutating the original, but let me know if it's better the other way.

[Golodhros]

Another way of doing this on an immutable way would be:

      // Remove the categoryId from the filters if the new value is empty
      const {[categoryId]: remove, ...updatedResourceFilters} = filterState[resourceType];

      newFilters = {
         ...filterState,
         [resourceType]: updatedResourceFilters,
      };

This would avoid the 'delete', that is a mutating operation (although made on a copy of the object)

@Golodhros I did it this way at first actually, but found I was getting a linting error because the remove is an unused variable. I didn't know if it was preferable to do it like this but then disable the no-unused-vars check for this spot? I figured the delete on the copy of the object was a middle ground to avoid linting issues but not directly mutating the original, but let me know if it's better the other way.

I see, try using '_' instead of rest, does that remove the warning?
If not, I would go ahead and disable the rule on this line!