Finish postponed SCAN changes

[zuiderkwast]

Commit 07ed0ea introduced some SCAN improvements, but some changes were postponed to a later version (8.0), which this PR finishes:

1. Prepare to move the TYPE filtering to the scan callback as well. this was put on hold since it has side effects that can be considered a breaking change, which is that we will not attempt to do lazy expire (delete) a key that was filtered by not matching the TYPE (changing it would mean TYPE filter starts behaving the same as MATCH filter already does in that respect).
2. when the specified key TYPE filter is an unknown type, server will reply a error immediately instead of doing a full scan that comes back empty handed.

Fixes #235

Release notes:

SCAN: Expired keys that don't match the TYPE argument for the SCAN are no longer deleted by SCAN

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 69.80%. Comparing base (72f2a87) to head (91d30f1).
Report is 4 commits behind head on unstable.

Additional details and impacted files

@@             Coverage Diff              @@
##           unstable     #501      +/-   ##
============================================
+ Coverage     69.67%   69.80%   +0.12%     
============================================
  Files           109      109              
  Lines         61801    61797       -4     
============================================
+ Hits          43062    43137      +75     
+ Misses        18739    18660      -79     

Files	Coverage Δ
src/db.c	88.15% <100.00%> (ø)

... and 11 files with indirect coverage changes

[madolson]

It's nice we wrote all these helpful comments in the code. We should do more of that.

[zuiderkwast]

Yes, in this case the code was already written but commented out before merge. Should we list it as a breaking change?

[madolson]

Yeah, as documented in the original issue:

1. Prepare to move the TYPE filtering to the scan callback as well. this was
  put on hold since it has side effects that can be considered a breaking
  change, which is that we will not attempt to do lazy expire (delete) a key
  that was filtered by not matching the TYPE (changing it would mean TYPE filter
  starts behaving the same as MATCH filter already does in that respect). 
2. when the specified key TYPE filter is an unknown type, server will reply a error
  immediately instead of doing a full scan that comes back empty handed.