Support filters in `SearchQuery` and `PatchOp`

[azmeuk]

RFC7644 indicates that SearchQuery.filter filter should have a given format:

filter  The filter string used to request a subset of resources.  The
      filter string MUST be a valid filter ([Section 3.4.2.2](https://datatracker.ietf.org/doc/html/rfc7644#section-3.4.2.2)) expression.
      OPTIONAL.

There should be a validator for this.

Related project: https://scim2-filter-parser.readthedocs.io/en/stable/

[azmeuk]

After giving some thoughts I can think of several places where filters are involved:

• GET requests on resources endpoints, in a filter query parameter.
• POST requests on /.search, in the filter parameter of SearchRequest
• PATCH requests on resources, in the path parameter of PatchOperation

GET & POST requests involves performing requests on all the objects of the server, where PATCH requests are limited to one single object. I guess for PATCH requests it would be easy to browse all items and select those which are matching the filters, but for performance reasons it cannot be done for GET & POST requests. I guess this is why scim2-filter-parser is useful.

@ccoors you mention this issue in the following LOC. Do you have any advice on using scim2-filter-parser as a dependency of scim2-models for filter management?

https://github.com/python-scim/scim2-server/blob/916b3bb30e70ccdf3ad30bd2c355b2d8dc49980e/scim2_server/filter.py#L20-L23

What are the limitations of your implementation? What could help if implemented here?

[ccoors]

Looking back now I can honestly say I don't know how that code works - that's a pretty major limitation :D I remember using the debugger a lot and trying to get the necessary information out of that scim2ast structure. Getting the field annotations for some of the attributes referenced in the filter was particularly tricky. There's a comment in line 57 # FIXME: Best guesses since there is no way to know for sure by this point so that was definitely an issue. Having the entire filter structure validated by Pydantic would also be nice, that could eliminate the check_comparable_value function.

On the other hand it has proven to be a robust enough implementation, that piece of code hasn't caused any issues for us yet - probably because in production you only ever see very simple filter queries if any.