ENH: Augment search methods

[shilorigins]

Description

• Change search term format from keyword arg to namedtuple of (<attribute>, <operator>, <value>)
• Define SearchTerm namedtuple
• Modify search page, views, and tests to use new format

Closes #61

Motivation and Context

SearchTerm Format

A three-term format provides more flexibility than a keyword arg. For example, we'd run into trouble using keyword args if we wanted to support both exact match and fuzzy match on entry titles, but with the tuple format we can apply different operators to the same attribute / value pairs.

Using a namedtuple for the format provides the option of setting and accessing args by name without taking more memory than bare tuples.

Operators

I included the operators:

• eq (equals)
• lt (less than or equal to)
• gt (greater than or equal to)
• in (item in container)
• like (partial match)
• isclose (number within absolute and relative tolerances)

lt and gt are both inclusive because I felt that that was more intuitive, and that we didn't need to also support exclusive versions. like currently supports regex string and UUID matches.

isclose takes an arg with format (<value>, <rel_tolerance>, <abs_tolerance>). The client converts this SearchTerm to lt and gt; the intention is that tolerances can be taken from the user or from the Entry directly, which the client turns into upper and lower bounds.

entry_type requires special handling because type comparisons need subclass information.

Tags

FilestoreBackend implicitly supports tags using the gt operator, but a dedicated operator may be required when other backends are added. To find entries whose tag set contains all tags in a filter, use the conditional ('tags', 'gt', {<tags>...}), which calls set.__ge__. Supporting more complex tag filters, like inversion or disjunction, will also require a tag operator or using Flag functionality.

How Has This Been Tested?

Existing tests in test_page, test_window, and test_backend.
New tests for lt, gt, fuzzy match, and tag filters.

Where Has This Been Documented?

This PR

Pre-merge checklist

• Code works interactively
• Code follows the style guide
• Code contains descriptive docstrings, including context and API
• New/changed functions and methods are covered in the test suite where possible
• Test suite passes locally
• Test suite passes on GitHub Actions
• Ran docs/pre-release-notes.sh and created a pre-release documentation page
• Pre-release docs include context, functional descriptions, and contributors as appropriate

[tangkong]

I like this a lot. I think it gives us a lot of opportunity to make some robust search functionality.

I do have some concerns about user friendliness at the Client-level, but I think everything behind that (backend, GUI) is fine as written.

[ZLLentz]

I really like the flexibility this gives us in the search

[ZLLentz]

This looks clean to me. I had one side thought but do not take it as a call to action.

[ZLLentz]

Something I hadn't considered in the previous PRs: would it add value to check that the results match the searches in the test suite? Or is this not worth the effort? I'm not sure but I thought I'd mention it.

for res in results:
    assert res.data <= 3

[tangkong]

I'm onboard, I like this implementation a lot.

A few nitpicky comments from me, none of which should hold up merging of this PR

[tangkong]

The github diff rendered part of this as italics... strange

[shilorigins]

It behaves weird with my vim highlighting too. Maybe the double ** is a parsing edge case?

[tangkong]

It renders funny in sphinx too, the * ends up being a hyperlink to an id anchor? This is something we can fix up when we actually publish release notes though

[ZLLentz]

Later we can add backticks around these to force them to be literals

[shilorigins]

I had to edit the collection builder page merged in earlier today, so I appreciate your re-approval 🙏