rip out the separate input/output sync thread model and the associated shared work queue of hashes from the other end, with sadness.

that architecture was desirable because it helped get better utilisation of threads locally since we could be hashing rows in a second table while we are waiting for a response to the hash we sent for an earlier table.

however, this necessitated a shared work queue which meant that replacement row data could come back in to any combination of the different workers (albeit only one at a time), and this turns out not to work with innodb's implementation of unique keys, specifically the way that (even in read committed mode) it uses a shared next-key lock to defend against the possibility another thread will try and insert into the same unique key 'hole', and that means we may not be able to replace rows in tables with a unique key if we have already replaced some unrelated rows in the same table in another worker (it will detect a deadlock or simply block until the other worker commits - which in fact it won't do since it is waiting for this worker to finish, meaning the blocked worker eventually times out).

so we have no choice but to go back to the simpler non-pipelined implementation that processes one table at a time (still sharing the queue for the tables not yet being worked on).
add --verbose option