This is a follow up to WT-18170, assuming that is successful in reducing latency and increasing throughput for standby reads.  Whereas WT-18170 merely opens the btree, we also want to warm any "needed" btree before use.  A simple plan might read in a level or two of internal nodes.  I think a more effective and efficient plan is as follows:

A layered table will have a small set (half dozen??) of "wanted keys".  If we're opening a layered cursor, have the old checkpoint open, and would normally "upgrade" to the latest checkpoint, this is the situation where in WT-18170 we mark the layered as "wanted", and continue to use the old checkpoint.  We do all that, but also, at the first set_key call for this cursor (or cursor->next or prev), we put the requested key into the "wanted keys" (if the wanted keys isn't already filled).  When the background open thread opens the wanted layered table, it also does a search_near for all the wanted keys, thus warming the cache, before declaring the new btree to be open for business.

To minimize allocations during cursor operations, we keep the allocated space for the previous set of wanted keys, and use realloc.  So over the course of checkpoints, we generally do very little allocation, except for the very first checkpoint pickup for that table.

This will tend to be most effective for localized workloads - we'll tend to bring in specific internal pages and leaf pages for keys we care about, leaving out sections of the tree that we aren't accessing.  For completely random key accesses, it will tend to bring in a variety of internal nodes (always welcome for such a workload) and some leaf pages that may or may not be useful.  Most workloads tend to have some locality so should benefit from this approach.