Live restore tracks which data needs to be read from the source versus destination files using a hole_list. Currently this list is not protected from concurrent modifications of accesses, so it's possible:

• Thread A reads the hole list and sees range 1000-2000 should be read from source
• Thread B writes to 1000-2000 in the destination
• Thread A uses the outdated content from the source

There's a good chance this specific case is handled in the WiredTiger dhandle code, but it warrants investigation. We should also think about scenarios involving the background migration thread.

The initial scope for this ticket can be adding a lock at the live_restore_file_handle level to sequential-ise all file accesses. Then we can review more granular locks - potentially we only need to protect the hole_list with a rw lock.

It would also be niceToHave some stress testing as part of this ticket. But that work can be broken out depending on the effort required.