Attempting to expire a committed item while a prepare is in flight generates new seqno for expiration/delete

While looking at MB-43176 I found that we were incrementing expiry stats for unsuccessful expirations (i.e if VBucket::processExpiredItem returned something other than a "success" response). Whilst trying to find a unit test that attempts to process an unsuccessful expiration I instead found that expirations are successful even if we have an in flight prepare for the same key. This expiration then generates a new seqno/item for persistence.

On the active node this probably doesn't have much impact unless we're warming up a partial snapsnot (in which case we won't warm up the prepare as it has now been "completed", this would be a data loss scenario anyway it's just slightly worse now) .

On the replica node this appears to cause us to return the error back to the active node when we process the expiration as we have an in flight SyncWrite. As far as I can see the active should tear down the connection at this point. Restreaming the expiration from disk to the replica would "implicitly" complete the prepare. A subsequent commit would then fail with ENOENT which I think is returned to the active and causes another disconnect. A subsequent disk stream would then work correctly as far as I can tell.

Going to write a cluster test to verify the replica side of things.