* Fix a bug found by inspection in LZ4 code: we're going to offset the destination buffer by sizeof(LZ4_PREFIX), so we need to offset the destination buffer length by the same amount.
* Prettiness pass through the snappy driver so it and the zstd driver look the same, minor cleanup in zlib.
* Add the compression_level configuration option to the zstd extension initialization function so it's possible to set the compression level from an application.
* Fix a bug in zlib raw compression: the destination buffer size (dst_len), can be smaller than the target page size (page_max), use the smaller of the two values to set the target compression size.
* The zlib raw compression function could return without calling deflateEnd on its z_stream structures, potentially leaking memory and scratch buffers.
* If the default reserved bytes for zlib raw compression isn't sufficient, we fail on compression of what might be very large blocks. We don't have information on how many bytes need to be reserved in order to know the final deflate() will succeed, and the default value was experimentally derived, for all we know there are workloads where the default will fail
a lot. Add a fallback before failing hard, try with 2x the default reserved space.
No longer support setting the statistics_log path in WT_CONNECTION::reconfigure.
No longer support setting a custom name for statistics files, only allow a destination directory.
Be more explicit about which logging configuration options are allowed in WT_CONNECTION::reconfigure.
The aim of these changes is to avoid situations where applications that embed WiredTiger allow their users to overwrite unexpected files on a file system.
This potentially requires an upgrade step for applications that were specifying a non-standard file name component for statistics log file names, it's not backward compatible.
Add an example of the code to open a cursor for incremental backup.
Wording changes:
Remove the requirement that a checkpoint be run between the full backup
and the incremental backup; it's not really a requirement and it implies
coordination between checkpoints and recovery that could be difficult.
Don't mention the backup database becoming "live" as the terminating
condition for incrementals, once you run recovery, it's over, you cannot
backup to that database copy again.
Note the log file grows rather than "changes in size"; it better not
shrink in size, applications won't be able to handle that.
Clean up thread-safe vs. global "display error strings" documentation:
the global code snippet was wrong, there wasn't a java thread-safe
snippet, add a mention of the thread-safe API to the error-handling
page, quit trying to enumerate the underlying strerror(3) standards.
In all java examples: declared main() correctly for picky JVMs, print stack
traces on exception, brought examples in line with C code.
In java examples, use Process.waitFor() to wait for 'rm' to complete.
Modified examples to use new record methods (e.g. getKeyRecord() instead of getKeyLong()) when appropriate.
Fixed key/value comparisions in ex_log.java example.
