Ephemeral tombstone's delete time can be incorrect

This MB is a follow on of MB-33919, forward merge of the fix has triggered failure in some tests that exist in master but not alice (where MB-33919 was committed).

The issue is isolated to ephemeral buckets only.

The code to set the tombstone exists in Vbucket::queueDirty and works by updating the queued_item with the tombstone time to use.

The bug is visible in a test that does a DCP backfill.

• In persistent buckets this works as the queued_item will be used for DCP and writing to disk, a later disk backfill will read items from disk and see our generated delete time.
• In ephemeral the queueDirty queued_item is only consumed by in-memory DCP. If a DCP backfill occurs, DCP is fed items from the hash-table's seqno ordered linked-list, and the OrderedStoredValue representing the tombstone still has the original expiry time set by the client, and as demonstrated by MB-33919 could be junk.

However in-terms of tombstone purging, MB-33919 does not fully occur because the OrderStoredValue has a separate tombstone field for the tombstone time, any replica built with backfill items though will use the wrong tombstone timestamp.

That is

• An item deleted/expired will on the active have the correct tombstone time
• Any backfilled DCP delete though is not get given the proper delete-time, a delete-time of 0 for example is used for items with no expiry, otherwise the raw expiry is used. For KV replica's fortunatley when processing an incoming DCP deletion, the OrderedStoredValue has the deletion time set by the delete path, so an incorrectly on-the-wire value of 0 is corrected to something sane. However re-calculating the delete-time allows for MB-27457 to occur.