[BP 7.2.5][XDCR] Raceful handling for topology errors

Note: This is uncovered due to MB-52547. This normally is not something of concern, explained below.

As part of collection, XMEM now recycle objects to be reused.

https://github.com/couchbase/goxdcr/blob/e7e96f60ac5fdbf67f8af5d9706aa905dc74dc52/parts/xmem_nozzle.go#L2687-L2691

When XMEM receives a topology change, XDCR will recycle the object, but never evict the buffer. This means that the retry timer will kick in and try to resend the object.

By this point, the object has already been recycled. This means all the opcodes, document key, has already been cleared. The resend mechanism will retrieve the position from the buffer, and try to resend the request. This presents two issues:

1. The request's opcode is no longer SET_WITH_META, but GET (0x00)
2. The request's doc Key is nil

Fortunately, under normal circumstances, this corrupted GET command is issued to the target node, and another NOT_MY_VBUCKET response is returned. This re-occurs until pipeline restarts. (The retry is also a waste of resource). So, the corruption usually doesn't show up in production.

For MB-52547, the issue happens where the VBUCKET is actually valid, and KV returns "NOT_BUCKET" instead. And the resend actually issues a completely empty GET command, resulting in some odd error response back.

This needs to be fixed for correctness. Another MB will be opened to address the assumption that "NOT_BUCKET" is the same as "NOT_MY_VBUCKET".