We should add test cases to verify that block-incremental backup behaves correctly when the last block of a file changes size between successive incremental backups.  Note that "block" in this description refers to the block sizes that incremental backup uses to track changes in WT files.

I believe what should happen in these cases is:

1. If the block size changes but the block contents don't change, the block is not marked as dirty.
2. If the block changes size and data in the block changes, then the block should be marked as dirty
3. If the block doesn't change size, but its data changes, then it should be marked as dirty.

#1 should only be possible when the file is truncated.  If the file grows, then by definition we should have written new data to it and the final block will be dirty. 

Ideally we should check that this behaves correctly even if there are multiple grow/shrink operations between backups, including cases that extend the file multiple blocks before returning it to the size at the previous backup.  

We have existing tests — format, and incr_backup — that perform random operations on files and create backups.  So these test should eventually cover the cases described here, but it would good to have targeted tests that verify correctness in these scenarios.