head_only mode cna be run with_lookup - but there is no L0 index created in this case.
So the L0 index wasn't returning a potition list and the L0 cache wasn't being checked.
Code now checks every position in the L0 cache, when a lookup is attempted in head_only mode.
There were some bad specs in '|' OR'd specs. These were being falsely ignored in dialyzer until https://github.com/erlang/otp/pull/1722.
Running on OTP21 exposed these incomplete specs.
The scan_table situation where the query needs to be start inclusive, was consistently getting coverage. It was less likely to get coverage with smaller cache sizes.
It is not clear why this wasn't being triggered before. Perhaps because of the erroneous jitter setting?
Multiple cache sizes now tested to try and make sure the test is always in-line with expectations.
Interetsingly setting max_pencillercachesize to a non-integer merely had the impact of making the penciller cache size infinite.
So a guard added to make sure it is an integer going forward.
Make it easier to discover all the options and the defaults from reaidng the code.
Note default sync option is now none. This doesn't mean this is recommended
Unit test needed to capture a bad key scenario, which did not get returned false. However, bad keys are now CRC checked and so willalways return false - and so the case clause for bad key can be dropped.
There are now two cases of safe_read_next_key/2
the first case using the original function name will return just the Key when positive (not the Key and KeyBinary). If the Key and KeyBinary is required (e.g. for CRC checking purposes), then use safe_read_next_keyint/2.
So that a corrupted key is detected through a CRC check without crashing leveled (e.g. because it binary_to_term/1 failes somewhere or it is a tuple of the wrong length).
Previously the CRC covered the value only.
Note if you only wish to extract the value, the key cannot be independently validated. Perhaps a process extrating key only could hit issues.
An issue was spotted. If we use a segment filter in a query, and there are multiple matches within a given slot - only the first match is returned.
Tests didn't detect this. Now they do, and the issue is resolved.
Previously couldn't accumulate keys using check-blocks - so if a key was found in the first position, and there were other positions to check for other keys, those other positions wouldn't be checked.
