[#710] Fix replication catch-up re-sending updates with the original assured flag

[vharseko]

Fixes #710.

Problem

When a peer (RS or DS) is not "following" — its ServerWriter is catching up
from the changelog DB rather than being served from the in-memory queue —
updates were delivered with the assured flag, mode and safe-data level of
the original sender.

ReplicationServerDomain.put() persists the original wire bytes via
publishUpdateMsg() before building the NotAssuredUpdateMsg, and the
substitution that strips the assured flag for non-eligible peers only happened
on the in-memory queue path (addUpdate()). MessageHandler.getNextMessage()
in the not-following branch re-reads the update from the changelog
(fillLateQueue()) and ServerWriter published it as-is. Every peer starts in
catch-up mode right after the handshake (following = false), so even a
just-connected peer receives its first updates through the changelog path.

Impact

• A peer that must never be asked for an ack (RS from another group, or any RS
  once a safe-data level 1 update is satisfied) received the update with
  assuredFlag: true and replied a spurious AckMsg, skewing assured
  monitoring counters and silently violating the "assured does not cross group
  boundaries" contract.
• New finding while fixing: when the spurious ack arrives while the ack
  window is still open (very likely, since catch-up delivery happens ms after
  publish), ExpectedAcksInfo.processReceivedAck() auto-unboxes a missing map
  entry (boolean = map.get(unknownId)) and throws a NullPointerException.
  It propagates out of ServerReader's loop, closing the connection to the
  acking peer — which reconnects, is in catch-up again, and can flap under
  steady assured traffic.
• This made AssuredReplicationServerTest.testSafeDataLevelOne and
  testSafeReadOneRSComplex fail stochastically on CI (see Enable the remaining slow-group tests in the default build #702, worked around
  there by waiting until all peers are following).

Fix

Two independent parts:

1. Normalize on both delivery paths. Move the substitution into
   ServerHandler.take(), the single point feeding ServerWriter from both the
   queue and the catch-up path. The assured flag is kept only while the ack
   window is still open and this server was eligible for an ack when the
   update was received (ReplicationServerDomain.isExpectedAck(csn, serverId)
   consults the live waitingAcks entry). This also resolves the corner case
   raised in the issue: a peer already in expectedServers keeps assured;
   everyone else (different group, connected after put(), expired window) gets
   a NotAssuredUpdateMsg. Assured counter skew is fixed as a side effect.
2. Harden processReceivedAck() in both SafeReadExpectedAcksInfo and
   SafeDataExpectedAcksInfo to ignore acks from servers that are not expected
   instead of raising a NullPointerException.

Tests

• ExpectedAcksInfoTest (new, precommit) — unit tests that an ack from a
  not-expected server id is ignored (no NPE) for both safe-read and safe-data.
• AssuredReplicationServerTest.testCatchUpClearsAssuredFlag (new, precommit) —
  deterministic regression test: an assured update is published to the
  changelog before a fake RS connects, so it is served through the catch-up
  path and must arrive non-assured. Verified this test fails without the fix
  (received update assured flag is wrong ... assuredFlag: true) and passes
  with it.
• Existing testSafeDataLevelOne/High/SafeReadOneRSComplex precommit tests stay
  green (queue path still keeps assured for eligible peers). 23 test runs, 0
  failures.