a moveChunk that joins the active moveChunk on a shard may not respect its waitForDelete

moveChunk's are considered equal even if their 'waitForDelete' options do not match:

https://github.com/mongodb/mongo/blob/r3.5.10/src/mongo/s/move_chunk_request.cpp#L159-L170

bool MoveChunkRequest::operator==(const MoveChunkRequest& other) const {

    if (_nss != other._nss)

        return false;

    if (_fromShardId != other._fromShardId)

        return false;

    if (_toShardId != other._toShardId)

        return false;

    if (_range != other._range)

        return false;

    return true;

}

However, only the active moveChunk acts on its 'waitForDelete' option.

So, if the active moveChunk has waitForDelete=false, a moveChunk that joins it will exhibit waitForDelete=false behavior even if it has waitForDelete=true.

A quick fix for this is to include the 'waitForDelete' option when comparing moveChunk requests. This way, if a later moveChunk's waitForDelete does not match the active moveChunk's waitForDelete, the later moveChunk will fail with ConflictingOperationInProgress rather than succeeding silently.

A longer fix is to refactor the schedule range deletion and waitForDelete behavior so that it is done by each moveChunk request according to its own waitForDelete option. This would allow a later moveChunk to join the active one for the actual migration, but wait for delete independently.