Context
After WT-16052 and WT-16053, we should have an extension example module and the ability to read/write to the turtle file. During checkpoint, if we encounter a new key blob we need to write the new lsn reference to the turtle file.

When a checkpoint occurs (triggered by a WT_SESSION->checkpoint call by mongod, the following steps occur:

1. WT writes dirty pages for btrees (these are PALI writes) these return LSNs - the LSN for the root page of each tree is started (as part of a checkpoint cookie) in the metadata btree.
2. WT writes the metadata btree, the last Btree to be written (via PALI writes) - the LSN for the root page of the metadata btree is saved (used in a later step)
3. WT calls the new API get_key_blob to retrieve the current KEK blob. If the call indicates that no changes were made (since the previous get_key_blob) call, then steps 4 and 5 are skipped, and we use the previously saved LSN for step 6.
4. WT puts a small header in front of the blob and writes the result to the KEK page (via PALI write) the LSN is used in step 6.
5. WT calls the get_complete API to return the LSN to the encryption layer, and to discard the memory used to store the blob.
6. WT creates the turtle page. Within the turtle information is the saved LSN for the metadata btree, also the LSN for the KEK page.
7. WT writes the turtle page via PALI write. The LSN returned is part of a string given to MongoDB, as it uniquely identifies the checkpoint.

This ticket will focus on writing the header information during PALI write in step (4). There has been dicussions on what the header might include:

• Unique ID
• KEK version
• Size of header
• Size of buffer
• Checksum

Test Plan
We need to ensure that turtle key provider information is persisted after re-open or crash. The key provider information must be updated and shown after a key rotation.

Defintion of Done

• The key provider config exists on the turtle page
• Tests scenarios are created using example and mock module