Standardize and improve search functionality

[tgianos]

This PR addresses two issues:

1. Job search by id and name was degrading at large job database size. It was performing a LIKE no matter what string was passed in. Now the code searches for the presence of the % character and if it's not present it switches that predicate to be an EQUAL

2. String fields across resources were treated differently. Some were defaulting to EQUAL predicates and some to LIKE predicates. Now all string fields supported by the API for search will use EQUAL by default and switch to LIKE if a % is present

[coveralls]

Coverage increased (+0.02%) to 89.191% when pulling b8ef4db on tgianos:3.0.x into aba7ab6 on Netflix:3.0.x.

[ajoymajumdar]

How do we differentiate '%' and '%'?

[skwslide]

What about the underscore character? It's a valid wildcard character for LIKE.

[tgianos]

@skwslide the scope of this work wasn't to address the edge cases that exist in the characters it was to:
a) improve the speed of job search
b) consistently handle all strings in search APIs

From an API perspective we shouldn't bleed through underlying implementation details like what the backend data store wildcards are. For now we've always used the % character in the UI to represent the wildcard character so this PR continues that assumption at an API level. At an API level we don't support other wildcard characters right now. To put in more advanced backend storage wildcard parsing / edge case handling we'd have to work on that in a separate body of work

[skwslide]

@tgianos, you want to expose only % as wildcard, and I agree with that. (I'm fine with having only % and having both % and _ as wildcards.) Two points to note:

1. Before this PR, _ was a wildcard. So, the first half of this PR is not just a performance improvement but also a change in semantics (regardless whether the old semantics is wanted or unwanted).

2. The new semantics is that _ is a wildcard if and only if % is present in the string. Therefore, this PR is still bleeding through some of the underlying implementation details and is just partway toward exposing only % as wildcard.