Add support for partial matching in the wildcard query

[LinZhihao-723]

Description

In most cases, users want to search for any result containing the given wildcard search string. This is implemented as "partial matching", which is the default search query in clg. This PR implements partial matching as the default option when building the wildcard query.
In terms of the low level implementation details, a partial match wildcard query "${WILDCARD_STRING}" is equivalent to the full match wildcard query *${WILDCARD_STRING}*.

Validation performed

1. Update the unit tests to cover the partial match.
2. All linters passed.

[davidlion]

Lets rename get_uncleaned_wildcard_query. Maybe something like get_original_query_string or get_user_query_string. I don't think we need to explicitly call it a wildcard query considering this is a method of the WildcardQuery class (so pretty redundant). I'm a bit indifferent about adding _string as a suffix, but it would probably be necessary if there is ever a Query class in the future.

[LinZhihao-723]

Agree. I will keep the suffix _string to differentiate it from the actual query and the input.

[junhaoliao]

As we discussed offline, without partial matching, the current .search() behaviour has caused confusion among users. Shall we revive this PR?

[LinZhihao-723]

As we discussed offline, without partial matching, the current .search() behaviour has caused confusion among users. Shall we revive this PR?

@kirkrodrigues I think we have a clear use case where users want the wildcard to be automatically surrounded by *

[kirkrodrigues]

As we discussed offline, without partial matching, the current .search() behaviour has caused confusion among users. Shall we revive this PR?

@kirkrodrigues I think we have a clear use case where users want the wildcard to be automatically surrounded by *

Things are a little awkward because users are already using this library in production and the recommended practice is not to change APIs without a major version bump; to support new functionality before the major version bump, the recommendation is to mark the current API for deprecation and then add new APIs with the new functionality.

In light of that, my proposal would be:

• Add two new classes---SubstringWildcardQuery and FullStringWildcardQuery---that are derived from WildcardQuery.
  • I prefer this compared to a flag since it makes the scope of the query clear.
  • Internally, SubstringWildcardQuery can call the WildcardQuery constructor with the added prefix & suffix wildcards. Eventually, if we need to move the prefix/suffix logic lower in the call hierarchy (e.g., for debugging as you suggested initially), then having a separate class makes this simpler.
• Mark WildcardQuery for deprecation. In the future, we can make it abstract like @davidlion suggested when we discussed this initially.
• Mark QueryBuilder's add_wildcard_query for deprecation and add a new version of add_wildcard_query (using Python's syntactic sugar for method overloading) which takes a WildcardQuery instead.
  • One advantage of this new add_wildcard_query is we don't have to keep changing the API of add_wildcard_query whenever the WildcardQuery constructors change. It's also more consistent with add_wildcard_queries.

[LinZhihao-723]

The equivalence has been implemented in PR #62