We had client-side notification stacking in the tray since launch, but now we want to stack notifications in the notifications page, in API responses and in email bundles.
Instead of writer pinning, we'll track the last transaction ID of each
write in the session. Then on each read we'll wait for the replica to
report that this transaction is available.
If it doesn't become available within a reasonable timeout, we'll
proceed anyway, and accept the possibility of a stale read.
The hope here is that most of the time, the replica is caught up in the
time between a write request and the following read request. If it's
not, we now have a little tolerance to wait for it, which hopefully
proves enough to stale reads are not encountered in normal use.
We also disable the writer affinity opt-out mechanism that we had
before, since we will no longer be using writer affinity at the load
balancer.
Previous code assumed that there was a single notification to dismiss
for that card, but in practice there can be zero or many. If it's zero,
we need to avoid the crash. If it's many, we should dismiss them all.
Also re-rendering the notification stack after dismissing enables us to
remove all the removed cards, as well as reveal any older ones that were
previously outside the visible page size.
This reverts commit 6135909b7e.
Stanko K.R.