On a resend response, when fetching the proto payload from the MSL, some
incorrect float math led to an off-by-one timestamp for some timestamps.
One example is the timestamp 1629210680140. When converting to a date:
1629210680140 / 1000.0 = 1629210680.1399999
Then when converting back to milliseconds:
Int(1629210680.1399999 * 1000.0) = 1629210680139
To fix this, the MSL now only operates with UInt64 millisecond
timestamps.
Fixes a bug where a incoming delivery receipt can race with an
in-progress send.
- When a message is preparing to be sent, a payload is inserted
- As sends are successful, recipient entries are added to indicate that
we're awaiting delivery acknowledgement.
- Once all recipient entries have been cleared (every recipient has
acked), we delete the payload.
If a message is being sent to A and B: A succeeds, but B is delayed, and
A acks before B can be sent, the payload entry will be cleared.
This change adds a "sendComplete" bit to the MSL table to indicate
whether or not the entry should be preserved even if all recipients have
acked.
Dictionary(uniqueKeysWithValues:) will assert that the provided keys are
unique and crash if a violation occurs. The existing code in
OWSReceiptManager falsely assumes that the addresses being built are
unique.
The keys in the key value store *are* unique, but as they're mapped into
addresses, we may have learned of a high trust e164/UUID mapping since
they were inserted. As the identifiers are mapped into
SignalServiceAddresses, the e164 and UUID are mapped to the same
SignalServiceAddress.
The fix is to just wrap our address builder in a Set() so we only have
one copy for each address.
