Context
After WT-16052 and WT-16053, we should have an extension example module and the ability to read/write to the turtle file. As such, we now implement the read KEK mechanism. 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:

#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.

1. 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)
2. 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.
3. 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.
4. WT calls the get_complete API to return the LSN to the encryption layer, and to discard the memory used to store the blob.
5. WT creates the turtle page. Within the turtle information is the saved LSN for the metadata btree, also the LSN for the KEK page.
6. 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 PALI mechanism to the new key provider table with no header specifically (3) and (5).The header will be filled in WT-16298.

Test Plan
Leadermode
Startup (on fresh WT): New KEK blob is written
KEK rotation -> crash: KEK blob is not persisted
KEK rotation -> checkpoint: KEK blob should be persisted

Defintion of Done

• WiredTiger calls get_key() during checkpoint
• Writes blob into PALI into the key provide table
• Tests scenarios are created using example and mock module