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.
