Before since we were setting the groupMetaMessage, it was setting the `shouldSave` property to true and thus the message sender was looking for the message in the db.
We now don't set this property so the message should be able to be sent without saving.
TODO
-[x] respect order of queue
-[x] replacements
-[x] those w/o completion handler
-[x] basic send+log operation persists
-[x] send+ui completion
-[x] share extension
-[x] update state jobs
-[x] App Lifecyle
-[x] settable
-[x] Mark as ready on startup
-[x] Fail appropriate jobs on startup
NICE TO HAVE
-[x] concurrent per senders
-[ ] longer retry (e.g. 24hrs)
-[ ] App Lifecyle
-[x] retry failed jobs on startup?
-[ ] reachability
DONE
-[x] basic passing test
-[x] datamodel
-[x] queue/classes
- removed timestamp parameter. This wasn't totally obvious, previously we were tracking two pieces of state
1. `unreadIndicator.firstUnseenTimestamp`:
the first unseen timestamp for a conversation that exists in the database
2. `unreadIndicator.timestamp`:
the timestamp of the first interaction *after* the unread indicator that fits in the loading window
We don't actually need to track `2` because it was only used in a comparison like:
viewItem.interaction.timestampForSorting >= unreadIndicator.timestamp
But by definition, unreadIndicator.firstUnseenTimestamp is always less than or
equal to unreadIndicator.timestamp. Put into terms of the `sortId` corallary,
the sortId of the first unseen interaction in the database is always less than
or equal to the sortId of the first unseen interaction that fits in the loading
window.
In other words, there's no situation where
viewItem.interaction.sortId >= unreadIndicator.firstUnseenSortId
No change in functionality in this commit, I just broke the signature to have a
systematic audit of the callsites. Added TODO's with the plan for each call.