rename vars in set_value() so they are understandable

end2 is not a clear variable name ;)
expand "offset > existing_size" case to return data written, not bytes

Before, sqlfs_proc_write() was returning the total number of bytes written
when it had to write blank bytes because of offset.  FUSE expects it to
just return how many bytes of actual data it wrote, not the blank stuff too
fix bug when setting end to 0 in set_value()

Setting set_value()'s end value to 0 should mean just write the whole
buffer out, but that logic was broke.
when truncating to expand file, set set_value()'s begin/end properly

Somehow these got hard coded to 0/0, which forces the truncate to always
make a zero size file.
change file size vars to size_t to get 64-bit file sizes on 64-bit systems

size_t is already used throughout for sizes, but perhaps it should be long
so that there are 64-bit file sizes on all platforms.

refs #3624 https://dev.guardianproject.info/issues/3624
refactor get_value() to write directly into the buffer given to it

Before, this code was allocating lots of memory, and making multiple copies
of things.  It would allocate chunks of memory the size of the entire file
no matter how small the read.  There is not need for such silliness since
a buffer and size is handed to sqlfs_proc_read() and sqlfs_proc_readlink(),
the two main users of get_value().  So this refactors things to just put
the data directly into that buffer as it is being read.
set_value(): no need to dynamically allocate tmp

To keep things simpler, just use a char[] so that the memory is released
automatically.
sqlfs_proc_write(): only clean_value() is memory has been allocated

No need to run clean_value() when 'value' is declared in the function and
the memory is not dynamically allocated.
set_value(): check the result of the previous block write before proceeding

It should not continue to write if one of the block fails to write, instead
it should throw an error and quit.  Perhaps this should be double-checked
against POSIX, but this approach makes sense to me.  Quit on error rather
than keep trying and risk more corruption.
quick and dirty python test script

This is meant to make it easy to reproduce specific patterns of reading,
writing, etc.
include script for running jenkins build
set WAL journal size limit to 10% of available space or 10M

Previously, there was no limit to the size of the WAL log file, and under
heavy load, it could grow quite a bit.  This sets a limit as either 10Megs
or 10% of the available space, whichever is larger.

refs #555 https://dev.guardianproject.info/issues/555
PRAGMA synchronous = NORMAL for higher reliability

Using the WAL mode should reduce the performance hit of using sync mode
enough to be usabel.

https://www.sqlite.org/pragma.html#pragma_synchronous

fixes #3662 https://dev.guardianproject.info/issues/3662
rename sql_key --> pthread_key to avoid confusion with db key

sql_key stores the pthread thread-specific key for retreiving sqlfs
pointers from the thread-specific store.  sql_key can easily be confused
for the key for the sqlcipher database.
zero out database key when done using it

This commit zeros out the stored password when the last instance is closed.
The password has to be stored for multi-threaded mode, since new threads
will need the password in order to access the database.

refs #3402 https://dev.guardianproject.info/issues/3402
standardize code format by removing wrong whitespace and brackets
remove dead or commented out code

This is all remnants of various debug efforts or half-implemented ideas
that don't seem to be required.

refs #1658 https://dev.guardianproject.info/issues/1658
bump library version to 1.3 since there are incompatibilities

The key/password API will break the old one, so at least bump the version.
add separate APIs for working with passwords and raw keys

If people are going to handle the password themselves, or for use as a FUSE
filesystem, then most likely, passwords will be the way to go.  For use in
IOCipher in conjunction with CacheWord, things work best if raw key data is
used.  That way CacheWord can pass the raw key data that it manages
directly to IOCipher.

fixes #3173 https://dev.guardianproject.info/issues/3173
tests: silence cppcheck unreadVariable and variableScope warnings

I have found that fixing the trivial warnings makes cppcheck more likely to
find real issues.