This comes out of the investigation in WT-17617. There is not yet a POC for this.

Currently, as checkpoint prepare operates, if a dhandle is deemed to be a candidate for a checkpoint (i.e. the btree is modified), we must do a check - if there is an ongoing metadata transaction involving the URI, the checkpoint is skipped for it.  This is a point search of the metadata.  For a large number of items in a checkpoint, the cost of point searches adds up.  For larger numbers, it may be faster to do a metadata scan looking for those active transactions (and we can limit the scan to in-memory pages).

This is one of those situations, where one can create a degenerate case:  A huge number of tables, but only a small number of them are open.  Clearly - the scan is more expensive.  If we want to handle this, then after WT-18062 is completed, we could know exactly how many items in the change list - how many times we'd do point searches, and potentially choose the point search approach when the number was reasonably small.

Part of the work here is also to measure before and after, and potentially add needed stats.