Handle In(key, []) and NotIn(key, []) correctly.

[danielballan]

This fixes an important bug in queries on the SQL-backed catalog. This bug is important particularly given queries' role in implementing authorization. The issue is that that In("color", ["red", "green"]) issues a query WHERE color="red" OR color="green" via the SQLAlchemy construction or_(...) where ... is a list comprehension of the possible values. But if said list is empty the effect is no restriction at all, this results in not additional filter on the results! When in fact the desired result is no rows returned: In("color", []) is a condition that no results satisfy.

This seems to be a recognized easy mistake to make; SQLAlchemy has deprecated the usage:

SADeprecationWarning: Invoking or_() without arguments is deprecated, and will be disallowed in a future release.   For an empty or_() construct, use 'or_(false(), *args)' or 'or_(False, *args)'.

This will be easier to review commit-by-commit:

1. Tested added that exercises the bug, and fails
2. Function refactored from conditional branching to dispatch, in a pattern that @padraic-shafer has taught me to reach for more often.
3. Bug fixed, passing test

Checklist

• Add a Changelog entry
• Add the ticket number which this PR closes to the comment section

[padraic-shafer]

Out of curiosity how should one query a key whose value is None?
...Is In(key, [None]) a valid usage, or must a Key have a non-None value?

[danielballan]

Any JSON-realizable value is valid, so In(key, [None]) would be a valid query. More testing on this with a range of types would be good for the future.