osd/PrimaryLogPG: avoid infinite loop when flush collides with write lock

osd/PrimaryLogPG: avoid infinite loop when flush collides with write lock

We try to take a write lock with fop->op.  If we fail, fop->op is put
on the lock's waiting list.  Requeuing it again will simply kick off
processing of another instance of the same op, which will again fail
to take the lock, leading to an infinite loop that can't terminate
because requeue_op is doing a push_front and preventing other PG
messages that might release the lock.

Do the same write lock attempt on any dup_ops so that they too will
end up on the wait list.

It looks like this broke waaay back in commit d700d99f76e0a29bfb419bc85d19ef1950b62a9a,
a 2014 refactor of the OpContext behavior.

Fixes: https://tracker.ceph.com/issues/23664
Signed-off-by: Sage Weil <sage@redhat.com>