As part of WT-6811, Luke noticed that the "out-of-order fixup" code appeared to be using the wrong value. I'm not 100% sure why timestamp20 manages to pass but I suspect it's to do with the fact that the leading garbage in the value does not translate to valid ASCII characters and may be dropped as part of the conversion to a Python string.

I wrote another test that uses modifies since I suspect that these would be more sensitive to corruption and was able to make the API return garbage and sometimes crash. I also ran into the issue that modifies aren't moved correctly since we don't pass the correct upd_type in (we just read a byte pattern corresponding to a modify and return it as if it were a real value).