Prefer returning None instead of using an FilterCondition::Empty state

[Kerollmops]

This PR is related to the issue comment meilisearch/meilisearch#1338 (comment) which exhibits the fact that when a filter is known to be empty no results are returned which is wrong, the filter should not apply as no restriction is done on the documents set.

The filter system on the milli side has introduced an Empty state which was used in this kind of situation but I found out that it is not needed and that when we parse a filter and that it is empty we can simply return None as the Filter::from_array constructor does. So I removed it and added tests!

On the MeiliSearch side, we just need to match on a None and completely ignore the filter in such a case.

[bidoubiwa]

I answered on the related issue with what I think raises my point. meilisearch/meilisearch#1338 (comment)
With this PR it fixes the problem I raised?

[curquiza]

@meilisearch/product-team can you confirm this is the behavior you expect?

[Kerollmops]

This is an issue that seems to have been raised when we switch from pest to nom, we used the Filter::Empty variant instead of returning an optional which breaks this behavior. It should never have behaved like this and don't restrict the results at all instead of returning nothing when the filter is empty.

The Filter::Empty variant was used in the previous parser version when a field name was unknown by the engine which means that no documents were matching this filter condition, as the field doesn't exist it matches no documents. This is no more required as the filter parser doesn't understand the unknown fields until it is given to the milli engine which returns an error when it happens.

[Kerollmops]

Thank you for the review!
bors merge

[bors]

Build succeeded:

• Run Rustfmt
• Tests on macos-latest with stable
• Tests on ubuntu-18.04 with stable
• Tests on windows-latest with stable

[gmourier]

@meilisearch/product-team can you confirm this is the behavior you expect?

This is consistent with the behavior of other fields like attributesToRetrieve which can be sent as [] for example. Since we have several possible filter syntaxes, it makes sense to be able to specify "" as [] for this field.