work around a TSAN report during multiprocess encryption

src/realm/util/encrypted_file_mapping.cpp

@@ -630,8 +630,25 @@ bool EncryptedFileMapping::copy_up_to_date_page(size_t local_page_ndx) noexcept
 
         size_t shadow_mapping_local_ndx = page_ndx_in_file - m->m_first_page;
         if (is(m->m_page_state[shadow_mapping_local_ndx], UpToDate)) {
+#if REALM_SANITIZE_THREAD
+            // Copying an entire page may overwrite arrays which is being read concurrently by
+            // another thread. This is benign because it overwrites data from old version with
+            // the same value as is already there, so the reader sees the correct value. This
+            // is all by design. However, when doing a memcpy of the entire page, TSAN sees
+            // this as a race even though we are replacing concurrently read data with the same
+            // values.
+            size_t num_bytes = static_cast<size_t>(1ULL << m_page_shift);
+            char* dst = page_addr(local_page_ndx);
+            char* src = m->page_addr(shadow_mapping_local_ndx);
+            for (size_t i = 0; i < num_bytes; ++i) {
+                if (src[i] != dst[i]) {
+                    dst[i] = src[i];
+                }
+            }
+#else
             memcpy(page_addr(local_page_ndx), m->page_addr(shadow_mapping_local_ndx),
                    static_cast<size_t>(1ULL << m_page_shift));
+#endif
             return true;
         }
     }

test/tsan.suppress

@@ -1,14 +1,5 @@
 # ThreadSanitizer suppressions file for realm-core
 
-# `AESCryptor::read()` and`copy_up_to_date_page()` copy entire pages.
-# They may overwrite something which
-# is being read concurrently. The reason it is benign, is that whenever there is a
-# race, it overwrites with the same value as is already there, so the reader sees
-# the correct value. This is all by design.
-
-race:realm::util::AESCryptor::read
-race:realm::util::EncryptedFileMapping::copy_up_to_date_page
-
 # Avoid a false positive instance of lock-order-inversion.
 # SyncManager::m_sessions_mutex and SyncSession::m_state_mutex are locked
 # in this order when a SyncSession is created, and in reverse order when