To get early signal, and to uncover any surprises we should implement a live restore performance test of sorts. The test will run as follows:

1. A database will be populated with 500m records. Is will serve as both the database to live restore from and the database to apply CRUD operations to.
2. Given the database perform two runs of CRUD operations, one run without live restore (which means that it is simply crud on top of an already populated databases) and a second run which live restores from the database while performing CRUD operations. Therefore we can compare the read and write latency metrics between the two.

The metrics should be uploaded as part of an evergreen task so that change point analysis can be performed on them.

At this stage the metrics outputted by the live restore run will serve as a baseline going into the future, additionally if they look particularly bad a performance investigation may be required.

To avoid reinventing the wheel leverage the btree-500m wtperf tests.