Add null check to mongo filtertransformer for KNOWN/UNKNOWN filters

[ml-evs]

Closes #254, by adding comparison against null during KNOWN/UNKNOWN filters.

This had to be added as another post-processor, due to the mismatch between Lark/mongo. There is also some additional logic to handle the case of e.g. NOT x is UNKNOWN. This was achieved by adding a dummy magic keyword "#known" when building the lark query, which is then expanded out by the post-processor after the NOT (expr) rule has been applied.

[codecov]

Codecov Report

Merging #279 into master will increase coverage by 0.09%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #279      +/-   ##
==========================================
+ Coverage   89.94%   90.03%   +0.09%     
==========================================
  Files          54       54              
  Lines        2248     2269      +21     
==========================================
+ Hits         2022     2043      +21     
  Misses        226      226              

Flag	Coverage Δ
#unittests	90.03% <100.00%> (+0.09%)	⬆️

Impacted Files	Coverage Δ
optimade/filtertransformers/mongo.py	97.02% <100.00%> (+0.34%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 53a22f8...d696d42. Read the comment docs.

[shyamd]

Looks good to me.

[CasperWA]

I like the use of all these postprocesses you've set up, cheers @ml-evs !

I am having some trouble wrapping my head around the logical consequences of what should be the result of each of these. I guess I should read the spec more carefully on these points.

[CasperWA]

It's quite a verbose edition of the transformer now, but with these things, it's for the better I think.

Cheers @ml-evs

[ml-evs]

It's quite a verbose edition of the transformer now, but with these things, it's for the better I think.

Cheers @ml-evs

Yeah, there's no other way to handle these edge cases with just lark, unless we can get to the field names directly (I gave up trying to do that a while ago). Hopefully this is the last one!

[CasperWA]

I think that would be a grave mistake, and if that is needed we have done something very wrong.