[maintenance events] 'none': consider rescheduling reconnect for connections notified after t/2

[ggivo]

Follow-up to #4625 (comment).

Problem

For a none MOVING, a connection created after the reconnect instant (t/2) can still land on the moving node and receives a re-delivery of the same MOVING. Re-deliveries from a known peer are ignored by design, so such connections stay on the old node until the server closes them at time_s.

Suggested investigation

When a new connection reports an already-known none operation after its reconnect instant — most likely with a newer, reduced remaining time_s — schedule another deferred reconnect at t/2 of the newly reported time_s instead of ignoring the delivery.

Notes:

• interaction with per-operation dedup ([maintenance events] Support overlapping MOVING events at pool level (CAE-3395) #4636)
• does the server re-send MOVING to new connections with the remaining (reduced) time_s?
• each rescheduled retire triggers a reconnect that may re-land on the old node while DNS still lags ;