If we rely on mNotificationList to be sorted, then we cannot allow
records to change without a corresponding call to sort. Currently
RankingFuture may modify records in a separate thread, while the sort
doesn't happen until later. This creates a window for race conditions.
Instead, RankingFuture should record operations to be performed on the
record that will replayed later, in a transaction along with a sort.
We can't simply overwrite the old record completely because another
future may be concurrently modifying a different aspect of the record.
Two futures that attempt to modify the same aspect will be serialized
and the second will overwrite eventually the first.
Change-Id: I9223cabdc60f72d8e37e6d8119bea1e0127185c0
(cherry picked from commit 77d3e0d0297caca5358879d36e8ba77710eb8e82)
470c1accf5