Update deps to tags for 2.0
Add failing key tx test

Change the default key transformation to only allow binaries. This will
make it have the same assumption that previous user defined key transforms
have had since they were created. It will fail if it gets passed a
{tombstone, Key} tuple, which is the problem being fixed here.
Run a merge with completely expired files, one of which contains a
tombstone. This will trigger the path that passes the {tombstone, Key}
instead of just the Key to the key transformer. This will fail with a
function_clause error as expected.
Skip tombstones on expired file merge

When merging completely expired files, we fold over them issuing
conditional keydir deletes on the entries of the file. That way, if any
of them are still present in the keydir, they will be deleted now
instead of the usual lazy delete on read, when we detect they are
expired.

Previously, the code was not accounting for the new {tombstone, Key}
return format when folding over the hintfile. A recent change in 1.7.0
added a tombstone bit flag to hintfiles, so now we can tell we are
dealing with a tombstone.  The tuple was being passed whole to the user
defined key transformation function, causing a crash. With this change,
we simply skip over tombstones. It makes no sense to try to delete them
from the keydir.
Add failing test for efile error

This test shows how if the cached efile port closes, our dumb ass can
not recover and Bitcask is unable to open casks. Yeah.
Recover from lost efile port

When the efile port cached in the process dictionary dies for any
reason, the code tries to load it one more time.  If we can not open a
new port, something is probably seriously wrong, so we stop.

This fixes the issue with efile ports going away, then Bitcask basically
getting stuck on the list_dir operation needed when opening a cask.

The bitcask:efile_error_test/0 will now pass with this change.
Add failing scan error test

This test demonstrates that when Bitcask's scan files operation fails,
a keydir object is created, not marked ready and left behind. Subsequent
open operations are unable to succeed because they try to wait for this
existing keydir to be ready when its data loads. But this will never
happen, so sadness ensues.
Fix scan error deadlock

If a file scan error happens during a Bitcask open operation, remember
to release the newly created keydir.  Before, that keydir was left
behind. Subsequent open operations would see it, see that it was not
ready yet and try to wait for it to load. But this would never happen,
alas.

If a scan error happens on opening a new directory, please release the
newly created keydir so other open operations have a chance to succeed.
Merge pull request #186 from basho/bugfix/key-transform-crash

Bugfix/key transform crash

Reviewed-by: jonmeredith
Fix remove expired on read race

If an expired entry is found in they keydir on a read operation, the
code immediately and unconditionally deletes it.  But the entry could
have been updated since the read, and we could end up deleting a new
value.

This commit changes the delete to be conditional. It will succeed only
if we are deleting exactly the same entry we found. If a newer entry is
found instead, the get operation is retried.
Merge pull request #189 from basho/bugfix/list-dir-port-refresh

Refresh efile port if gone

Reviewed-by: slfritchie
Merge pull request #190 from basho/bugfix/scan-error-deadlock

Fix scan error deadlock

Reviewed-by: slfritchie
Merge pull request #192 from basho/bugfix/expiry-remove-race

Fix remove expired on read race

Reviewed-by: slfritchie
Add failing update tombstones test

Our current delete scheme requires that updates write tombstones for
previous values when the previous value is in an file logically older
than the current write file.  An unrelated change broke that logic, and
now tombstones are written every single time a value is updated.

This test demonstrates this by counting the number of tombstones
expected for repeatedly updating the same key when two data files are
created. Only a tombstone is required, but we get one per update.
Fix extra update tombstones

An unrelated fix in commit 4ab96d4 caused updates replacing a value
in the same file to write extra tombstones that serve no purpose.
Updates are supposed to create a tombstone for previous values only
when the previous value was stored in an older file. Multiple
values for the same key in the same file do not require these extra
tombstones.
Add failing list data files race test

This test shows what happens when listing the readable files from a
Bitcask directory. The list should not include the active write or merge
files. But if those change after the code fetches the name of the
current one, the listing will contain the new active write and/or merge
files, skipping the *previous* write or merge file. That would be bad.

The test uses meck to return the filename, then in one go write a new
one to simulate the race.
Fix race listing readable files

A race existed as demonstrated by the newly added
list_data_files_race_test test. When listing readable files from a
Bitcask directory for merging and such, the current write or merge
output files should never be listed along with the other files. This
could lead to merges trying to read active files while they are being
written.

Now, the code fetches the current merge and write files, lists the
directory contents, filtering those out, and checks again if the merge
and write file have changed. If they have, we try again, only succeeding
if no changes have happened in between.
Merge pull request #197 from basho/bugfix/extra-tombstones-on-update

Fix extra tombstones on update

Reviewed-by: slfritchie
Merge pull request #198 from basho/bugfix/list-files-race

Fix race listing readable files

Reviewed-by: slfritchie
Staging 1.7 merge to develop
Merge pull request #201 from basho/merging-1.7.1

Merging 1.7.1

Reviewed-by: slfritchie