After milestone 2, the capability to set a sub-level error code and a message should be done. This ticket involves reproducing the schema lock and table lock 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_SCHEMA_LOCK, another thread is performing a schema operation
• EBUSY, WT_CONFLICT_TABLE_LOCK, another thread is currently reading or writing on the table

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.