WIP (do not merge): fix(rollups): Write rolled-up keys at ts+1 (#7957) (#7959)

[joshua-goldstein]

From original commit:

Write rolled up keys at (max ts of the deltas + 1) because if we write the rolled-up keys at the same ts as that of the delta, then in case of WAL replay the rolled-up key would get over-written by the delta which can bring DB to an invalid state.

(cherry picked from commit 3831b49)

Cherry pick from #7959. Curiously, CI-dgraph and CI-dgraph-load tests almost consistently fail on this change. See the checks for more info. It would be good to understand why checks are usually failing, and also to understand why they on occasion do pass.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ joshua-goldstein
❌ ahsanbarkati
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[coveralls]

Coverage increased (+0.01%) to 37.201% when pulling b79ad90 on cherry-pick-7959 into 9a2427e on main.

[joshua-goldstein]

With this change we see almost consistent failures in dgraph-load-tests and 50/50 passes and failures in dgraph-tests (see checks on the PR). This requires further investigation and should not be merged for now. Since this change was introduced after roaring bitmaps were introduced, it is possible there are missing side effects from that switch.

[mangalaman93]

yeah, I do not follow the reasoning either well. It could be a problem to use a timestamp ts+1 too with the same logic.

[matthewmcneely]

Good to see that the comprehensive CI test changes that @skrdgraph and the rest of the team implemented enabled us to see the issue in aggregate. It paid for itself here...

[joshua-goldstein]

Closing this as a fix will eventually be merged in #8759