After milestone 2, the capability to set a sub-level error code and a message should be done. This ticket involves reproducing the remaining EBUSY drop workflows and making sure that the get_last_error API works as appropriate. The idea is that the API should be able to provide more information on why an EBUSY has been returned from the drop() call. Follow these scenarios:

• EBUSY, WT_CONFLICT_BACKUP, the table is currently performing backup
• EBUSY, WT_CONFLICT_DHANDLE, another thread is accessing the table
• EBUSY, WT_CONFLICT_SCHEMA_LOCK, another thread is performing a schema operation  Moved to WT-14026
• EBUSY, WT_UNCOMMITTED_DATA, the table has uncommitted data and can not be dropped yet  Done in WT-13865, but still need catch2 unit tests
• EBUSY, WT_DIRTY_DATA, the table has dirty data and can not be dropped yet  Done in WT-13865, but still need catch2 unit tests
• EBUSY, WT_CONFLICT_TABLE_LOCK, another thread is currently reading or writing on the table  Moved to WT-14026

The expectation is that in each of the scenarios a SUB-LEVEL error code and message should be set.

Definition of Done
Unit tests and python scenarios are created where they reproduced the problem, and made sure that they return the appropriate sub-level error code and message.