I think there's some code clean up and refactoring we can do to improve duplicate key handling when inserting keys into an index.

In SERVER-111111, we'll branch some of the inserting logic for primary driven builds and duplicate some conditionals for retrying to insert when duplicate keys are allowed for unique indexes. 

1. Understand the reason unique indexes might allow inserting duplicate keys and verify if this case exists happens when draining the side writes table.
2. If the duplicate key handling is necessary, could this general insert path be improved to avoid calling WiredTigerIndex::insert twice? Currently, we check for dup keys when inserting but I wonder if WiredTigerIndex::_checkDups could be made public so that callers explicitly check themselves when necessary (like we do here) and separately insert after. The tradeoff is that currently, we can reuse the same cursor by calling _checkDups within WiredTigerIndex::insert.
3. Instead of exposing WiredTigerIndex::_checkDups, is WiredTigerIndex::findLoc sufficient for checking duplicate keys outside of draining side writes? When draining side writes, we can assume that we are not concurrently writing to the index however outside of index builds, we can have concurrent inserts to the index. I suspect using WiredTigerIndex::_checkDups is necessary for concurrent transactions.
4. WiredTigerIndex::_checkDups can return true or false but don't actually care about either but just that a bool is returned. This is currently true for all _checkDups callers so we might want to update the return type.