Best-effort fix for merging metadata over WAN after merge rejection […

…5.2.5] (#866)

Backports of:
#25629
https://github.com/hazelcast/hazelcast-enterprise/pull/6612
#25901

GitOrigin-RevId: 9faffc458a40d299637d2b1030c60c5fcb4ff4fd

hazelcast/src/main/java/com/hazelcast/map/impl/recordstore/DefaultRecordStore.java

@@ -1096,7 +1096,20 @@ public boolean merge(MapMergeTypes<Object, Object> mergingEntry,
             }
 
             if (valueComparator.isEqual(newValue, oldValue, serializationService)) {
-                mergeRecordExpiration(key, record, mergingEntry, now);
+                // When receiving WAN replicated data, it is possible that the merge policy rejects an incoming
+                //  value, which would result in the above condition being true (merge policy selects the existing
+                //  value as the outcome). However, we do not want to apply metadata changes if we are rejecting
+                //  the merge and sticking with our original data. Due to current limitations of the
+                //  SplitBrainMergePolicy, we have no view on whether the merge policy modified the outcome or not,
+                //  only the resultant value. Long-term we need to address this shortfall in merge policies, but
+                //  for now the additional check below allows us to make an educated guess about whether the merge
+                //  changed data and use that. Since this only matters for WAN-received merge events, we can avoid
+                //  additional overhead by checking provenance. Fixes HZ-3392, Backlog for merge changes: HZ-3397
+                boolean shouldMergeExpiration = provenance != CallerProvenance.WAN
+                        || valueComparator.isEqual(existingEntry.getRawValue(), mergingEntry.getRawValue(), serializationService);
+                if (shouldMergeExpiration) {
+                    mergeRecordExpiration(key, record, mergingEntry, now);
+                }
                 return true;
             }